www.pokedex.org - see bug description

[flaki]

URL: https://www.pokedex.org/
Browser / Version: Firefox for Android 45.0
Operating System: Android 5.1.1
Problem type: Something else - I'll add details below

Steps to Reproduce

1. Navigate to: https://www.pokedex.org/
2. Animations are laggy, slow performance on Firefox for Android (on Chrome, it's smooth).

More information on the bug:
nolanlawson/pokedex.org#35

[karlcow]

Thanks @flaki
I wonder if @hallvors could help here.

Running on desktop with a chrome mobile UA to bypass the UA sniffing
https://github.com/nolanlawson/pokedex.org/blob/e0d46357a25f37b7ed17e57ce36873ab8d3889f9/src/js/client/main/utils.js#L11-L21

And clicking around doesn't show any performance issues. So if there is an issue with Firefox Android, it's probably really specific to that context.

I can confirm it is laggy on Firefox Android.

In this screenshot of a performance recording when typing the first character on the top left and focusing on the moment where it seems stalled:

1. first DOM Event is the click
2. Then second DOM Event is animationstart
3. Then there is a long requestAnimationFrame around 450 ms which is mainly due to a Recalculate Style (195 ms) and a Layout calls (225 ms).
4. The subsequent requestAnimationFrame are around 2ms or less.

[karlcow]

https://www.pokedex.org/js/main.js has a couple of calls to requestAnimationFrame
The issue seems to happen when changing the StyleAttribute.

[karlcow]

I wonder if it's related to this bug https://bugzilla.mozilla.org/show_bug.cgi?id=949409

[hallvors]

I tested this on a Moto X and a Firefox OS Z3. Performance is not actually that bad here. @flaki do you know if some work was done here already?

When profiling I see lots of small chunks of style recalculation, but most of it seems related to animation/transition stuff, and short-lived.

Looking at Karl's screenshot, it would be very interesting to know what script set some element.style.foo to a value that caused 194 milliseconds of style recalculation. That seems really excessive.. There's a function o combining setting style properties and requestAnimationFrame here:

function o(e,t){requestAnimationFrame(function(){e.style.transform="",t.style.transform="rotate(90deg)",requestAnimationFrame(function(){e.classList.add("animating"),t.classList.add("animating"),e.style.transform="scaleY(0.01)",t.style.transform=""})

but of course I can't tell from a glance if this is indeed the code causing that log entry - though the scaleY(0.01) thingy seems like it might be expensive, depending on what it's applied to. (It also seems like a case a smart implementation might optimize away with shortcuts..)

PS: Bugzilla 949409 might be more about CSS positioning, can't tell if it's relevant.

[flaki]

Hi! Thanks all for investigating!
First, we added a switch in utils.js so the UA-sniffing could be avoided and high-performance mode activated without UA spoofing: https://www.pokedex.org/?highPerfAnims=1

With that, I'm testing on Firefox OS (Z3c, nightly-latest), and the most visible profiling issue does indeed seem to arise in those requestAnimationFrame-calls:

The performance on both Android & FxOS (Z3c both) seems rather similar, although FxOS seems more fluid (Fennec scroll performance feels a bit choppier, while FxOS is pretty smooth to the eye). My only concern, though, is the long (1-2 sec) delay after clicking a pokemon and their respective datasheet coming up - this is a very apparent difference from the Chrome version.

For the reason, I couldn't come up with anything (maybe the rAF issue above?), but testing on desktop does occasionally reveal the same issue (could this be a GC problem? Feels similar, indeed...).

Thanks for working on this! Sorry that I couldn't be of more help. :(

[nolanlawson]

Thanks to everyone for looking into this! I was really surprised by the results, since it's so smooth in mobile Chrome.

I'm basically following @paullewis's advice from "FLIP your animations" for these animations. Supposedly the requestAnimationFrame() (the expensive part) should complete in <100ms, which would be imperceptible to the user, and then the GPU takes over after that (via CSS transforms). It's possible, though, that I'm just exceeding this budget on Firefox but not on Chrome/Safari. (Both Chrome on Android and Safari on iOS have pretty smooth animations.)

Maybe this "FLIP" advice only works well for WebKit/Blink browsers? Wondering if I should have tried out the Web Animation API (with a polyfill) instead.

I'll note, however, that the scroll performance is also pretty laggy on Firefox compared to Chrome. It's been suggested in nolanlawson/pokedex.org#35 that excessive will-change might be the culprit there.

[wanderview]

Note, running this in a debug windows build gives me a bunch of warnings about bad surface sizes. This could be will-change at work.

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Failed to allocate a surface due to invalid siz
e Size(16384,16384)|[61][GFX1-]: Failed to allocate a surface due to invalid size Size(16384,16384)|
[62][GFX1-]: Failed to allocate a surface due to invalid size Size(16384,16384)|[63][GFX1-]: Failed
to allocate a surface due to invalid size Size(16384,16384)|[64][GFX1-]: Failed to allocate a surfac
e due to invalid size Size(16384,16384)|[65][GFX1-]: Failed to allocate a surface due to invalid siz
e Size(16384,16384)[GFX1-]: Failed to allocate a surface due to invalid size Size(16384,16384)
[6008] WARNING: Could not create DrawTarget for mask layer.: file c:/devel/mozilla-central/layout/ba
se/FrameLayerBuilder.cpp, line 6099
[GFX3-]: Surface size too large (exceeds allocation limit)!
[GFX3-]: Surface size too large (exceeds extent limit)!

I'm doing an opt build with symbols so I can get a better profile.

[hallvors]

Looking at profiles from Firefox (on device), one of the interesting issues is that Firefox needs a bit of time to handle the getBoundingClientRect() call after querySelector(".sprite-"+e). (150-200ms). I think this is causing the same style recalculation which shows up in Karl's screenshot. Interestingly, removing will-change from the CSS sems to slightly speed up that particular part, it does not however improve performance overall - I think rather the oposite. Most of the delay seems to happen in painting. Gecko does painting in long chunks where Chrome does smal spurts. Why this is requires a deeper anlysis than what I'm able to do. I think we need a Bugzila bug to follow up.

[hallvors]

Pokedex performance issues being investigated here: https://bugzilla.mozilla.org/show_bug.cgi?id=1227748