1340126 - twitch pseudo game for 2017 review is laggy

Status: RESOLVED INACTIVE

(Core :: Web Painting, defect, P3)

Description

[vmoutoussamy]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170216004023

Steps to reproduce:

Tried to play the pseudo-game at https://www.twitch.tv/year/2016/


Actual results:

The frame of the game is laggy


Expected results:

Smooth experience.

Comment 1

[vmoutoussamy]

Please let me know if you can reproduce this issue and if you need further details.

Comment 2

[Loic]

Could you join a perf log from the Gecko Profiler (in dev tools).

Comment 3

[Emil Pasca [:emilpasca]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0

I have tested this issue on a Macbook PRO machine with Mac OS X 10.12 and 10.11 with the latest Firefox release (51.0.1) and the latest Nightly (53.0a1-20170220030205) and managed to reproduce it.
After navigating to the provided URL in the description, and using the arrow keys to play the game, the scrolling animation has lag.

In the browser console the following message is displayed:
This site appears to use a scroll-linked positioning effect. This may not work well with asynchronous panning; see https://developer.mozilla.org/docs/Mozilla/Performance/ScrollLinkedEffects for further details and to join the discussion on related tools and features!

Here is the Gecko Profile: https://perfht.ml/2kHnMUL

The issue is not reproducible on Nightly 46.0a1, I have performed a regression, below are the results:

Application_version: 46.0a1
Narrowed nightly regression window from [2015-12-25, 2015-12-28] (3 days) to [2015-12-27, 2015-12-28] (1 days) (~0 steps left)
Got as far as we can go bisecting nightlies...
Last good revision: c39a71cf41460924d2988d2d63be2f5d267db82a (2015-12-27)
First bad revision: 7c83da46ea740bc14028aca9f9a662f062de5586 (2015-12-28)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c39a71cf41460924d2988d2d63be2f5d267db82a&tochange=7c83da46ea740bc14028aca9f9a662f062de5586


I have tested this issue on an iMAC with Mac OS X 10.12, 10.11 and a PC with Windows 10, Windows 7 with the latest Firefox release (51.0.1) and the latest Nightly (53.0a1-20170220030205) and the issue is not reproducible.

Kartikaya, do you think is this somehow related to Bug 1234950?
Thank you.

Comment 4

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

I'm not able to reproduce the problem. Can you describe the symptoms in more detail? In particular it's not clear to me if the issue here is jank or lagginess. If the animation is stuttery - so it stops and starts, that would be jank. If the animation is delayed relative to the keyboard input - so for example you push the right arrow key and a half second later you see the car moving, and when you release the right arrow key it again takes a half second for the car to stop - that would be lagginess. We can further divide lagginess into a fixed amount of lagginess (so the car is always a half-second behind keyboard input, for example) or a variable amount (so sometimes it's following keyboard input right away, other times it's a half-second behind).

Bug 1234950 does seem to be the most likely candidate of that pushlog but the intended effect of that bug was to just move some animations by one frame, which should barely be noticeable to the end user. So I'm surprised if that's the case here.

Comment 5

[Emil Pasca [:emilpasca]]

Thank you for taking the time to investigate this issue.

I think that the following videos could describe better the way the animation behaves on different machines.

Recording on a Macbook pro wit Sierra 10.12: https://goo.gl/ACkffH
Recording on a PC with Windows 10: https://goo.gl/e9mHWH

Do let me know if you need me to provide more info.

Comment 6

[Emil Pasca [:emilpasca]]

In both animations, I am constantly holding the right arrow key down, so I suppose is not lagging, as in both cases it detects the keyboard input. However the animation is stuttery, it stops and starts.

The expected behavior is the one as recorded on Windows 10.

Comment 7

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

Thanks! On my Macbook Air I see basically what you're seeing on Windows 10 - the animation is pretty smooth and not stuttery. From your profile it looks like we spend a lot of time rasterizing, and there's no compositor thread in the profile so it's a bit hard to tell exactly what's going on, but the long rasterizes might very well be a contributing factor here. When I profile the page locally I get quite different results - rasterizes are quick (~3ms vs your ~80ms) and everything looks as it should. I'm not sure why there's such a big difference between what you're seeing and what I'm seeing.

Comment 8

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

I kicked off a build at https://treeherder.mozilla.org/#/jobs?repo=try&revision=55364c000e6a0c333cb8853bed8fcc13cd5f200f - when it's done, can you check if you see the stuttery behaviour on that build?

Comment 9

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

Actually it looks like the try push isn't building. I'll find some other way to make that build, sorry.

Comment 10

[Matt Woodrow (:mattwoodrow)]

Had a quick look at this, texture upload on the compositor thread is taking forever. ClientStorage (bug 1265824) might help a fair bit.

The other issue is that the page is implementing side-scrolling by animating the left property. We're layerizing nicely, but we're using the single-tile content client (since we only use multi for scrolling), which only knows how to redraw when things move.

ContainerState::GetLayerCreationHint should probably treat animated left/top as scrollable for this case.

Comment 11

[Gregory Pappas [:gregp]]

Reporter, are you still experiencing this issue?

Comment 12

[Gregory Pappas [:gregp]]

comment 11

Comment 13

[Dave Hunt [:davehunt] [he/him] ⌚BST]

With no answer from the reporter, we don’t have enough data to reproduce and/or fix this issue. Please reopen or file a new bug with more information if you see it again.