1292013 - Firewatch website parallax animation lags in Nightly, OK in stable, Chrome, & Safari

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect, P5)

Description

[Jonathan Chan [:jyc]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20160803030226

Steps to reproduce:

1. Go to www.firewatchgame.com
2. Try to scroll up and down, observe the parallax effect


Actual results:

The parallax effect is very laggy and slow. This only happens in Firefox -- it's very smooth in Chrome and in Safari (haven't tested in IE).


Expected results:

The parallax effect should have been smooth.

Comment 1

[Jonathan Chan [:jyc]]

As far as I can tell, here is the script responsible for the effect: http://www.firewatchgame.com/js/firewizard.js . It's very short. This is the core of it:

	window.addEventListener("scroll", function(event){

		var top = this.pageYOffset;

		var layers = document.getElementsByClassName("parallax");
		var layer, speed, yPos;
		for (var i = 0; i < layers.length; i++) {
			layer = layers[i];
			speed = layer.getAttribute('data-speed');
			var yPos = -(top * speed / 100);
			layer.setAttribute('style', 'transform: translate3d(0px, ' + yPos + 'px, 0px)');

		}
	});

The parallax-affected elements have data-speed attributes that define how fast they scroll, and this just listens for scroll events then sets the CSS transform style to a translate in the y-axis. Not sure why this should be so slow, unless the scroll event listener is not firing often / it causes a lot of repaints (?)

FWIW, if I enable paint highlighting, every scroll increment seems to cause massive repainting on the whole page.

Comment 2

[Jonathan Chan [:jyc]]

I encountered the problem on Nightly on OS X, but I just tested this on stable on OS X and did not get the problem -- only the new areas are highlighted as repainted.

materializecss.com/parallax-demo.html is also janky on Nightly, but not on stable.

Comment 3

[Timothy Nikkel (:tnikkel)]

I think this is because of async pan zoom.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Yeah. Any parallax implementation that uses JS will have similar problems, because the scrolling happens asynchronously from the scroll event being dispatched to JS.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

I think Chrome does ok on this page because they paint faster than we do. Edge, on the other hand, does much worse - touch-scrolling this page in Edge is a disaster.

Comment 6

[Markus Stange [:mstange]]

Comment 16 sounds like there was an invalidation regression. Can we find a regression range for that?

Comment 7

[Kartikaya Gupta (email:[e-mail])]

I can reproduce the paint-flashing in nightly as well as in 48 release with e10s force-enabled. I don't think it's a regression, there's probably something on the page that's triggering a repaint across all channels.

Comment 8

[Jonathan Chan [:jyc]]

It doesn't happen without e10s in 48 release on OS X or Linux, though, and full-page repaints don't happen in either -- does that count as a regression?

Comment 9

[Botond Ballo [:botond]]

I'm seeing full-page repaints happen on 48 without e10s as well (tested on Linux).

Comment 10

[Daniel Holbert [:dholbert]]

(botond clarified in IRC that the "full-page-repaints" he mentioned seeing *only* happen as the scroll operation starts and stops [after the page "settles"], but not during a scroll operation (smooth-scroll or otherwise).  I see that same behavior, both in Firefox 48 without e10s and in Nightly 51 with e10s, on Linux.  I do see a slight delay in parallax stuff moving, in Nightly with e10s enabled, but other than that, Nightly-with-e10s looks pretty much like 48-without-e10s to me.)

jyc showed me some worse stuff happening on his machine with this page -- like parallax stuff having multi-second-long delays before moving (or never moving at all).  That is perhaps more serious (maybe something like the disaster kats hinted at in Edge, in comment 5).

Comment 11

[Kartikaya Gupta (email:[e-mail])]

P5 for the parallax issue. If there's a full-paint repaint issue we should split that out into another bug.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

WebRender makes this much better