1227748 - Investigate why pokedex.org has poor scrolling performance

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Potch [:potch]]

https://www.pokedex.org/ is being held up as an example of a strong "progressive web app". It's quite well done, but for some reason has poor scrolling perf in only Firefox. Ran a profile and it seems like the answer is "graphics".

Any thoughts? Bad for something being held up as a good example of a proper future-forward app to work poorly in only Firefox.

Comment 1

[u279076]

(In reply to Potch [:potch] from comment #0)
> Ran a profile and it seems like the answer is "graphics".

It would help to have access to that profile, also a copy of your about:support page.
 
> Any thoughts? Bad for something being held up as a good example of a proper
> future-forward app to work poorly in only Firefox.

Scrolling-wise I get similar results with Chrome and Firefox Nightly 45.0a1. The only difference I notice is that some items show up blank for a few seconds in Firefox but scrolling is otherwise fluid. Could you provide a better description of what you're experiencing and perhaps illustrate it with a screencast?

Comment 2

[Benoit Girard (:BenWa)]

For me it's a mix of (1) uBlock causing sync messages with e10s and (2) slow full page invalidation.

Comment 3

[Benoit Girard (:BenWa)]

Got time to look at the full page invalidation here? The test case seem interesting and it doesn't look like a full page invalidation should be required here.

Comment 4

[Matt Woodrow (:mattwoodrow)]

The main problem here is that the website seems to be using it's own 'display port', and is adding and removing items based on what it thinks is visible.

This is conflicting with our display port, and the webpage is removing items that are still visible within our, so we're getting lots of invalidations above and below the 'actual' visible area. It looks like region simplification is causing this to sometimes trigger full page repaints.

The page is also listening to the scroll event to trigger its code to add/remove items, and we're not firing this as often with APZ, leading to items being added later than necessary.

Comment 5

[Matt Woodrow (:mattwoodrow)]

The page also seems to be using will-change:transform just to get layers, it never actually transforms anything.

The top and left sidebars are (separately) wrapped in will-change:transform, as is all of the scrolling content (but not the background color).

Fixed position and scrolling content already gets layerized separately, so at best this just adds a small amount of overhead (since we end up with a pointless wrapper layer for the will-change).

The scrolled content however now gets a separate layer to the background colour, so we have two sets of tiles covering the content area. This doubles the memory usage, and since the top layer of tiles are partially transparent (we can see the background color under them), we have to pay the memset cost of clearing them every time we draw new sections.

Ideally we'd be able to convert the background into a ColorLayer (which doesn't require memory for a backing store), but we have both a background colour for the page canvas, as well as a background colour for the body element. These backgrounds cover different areas, and we don't currently have code to detect that they're actually the same colour.

Fixing this isn't too hard, but we'd be better off trying to get webpages to avoid using will-change:transform unless they really will change the transform.

Comment 6

[Matt Woodrow (:mattwoodrow)]

Most of the remaining CPU time is just blitting colours (gradients for the individual element backgrounds, plus the main backgrounds colours), and images.

Having a hardware accelerated rendering backend (like skia-gl, or d2d) would help a lot for this workload.

Comment 7

[Matt Woodrow (:mattwoodrow)]

I've seen a few webpages now using 'virtual displayports'; it might be worth considering finding a way to expose gecko's idea of what is currently visible (essentially our internal displayport) and convincing webpage authors to use that.

This page is currently using 0 <-> innerHeight to determine which pokemon to make visible, and has no way of knowing that we're rendering content outside of this area.

Comment 8

[Nolan Lawson]

For the record, I've removed the excessive `will-change`s from the live version of the site now. Instead, I mostly apply `will-change` in JS as part of the animation process.

The scrolling performance was not much improved, although the transition animation performance seems a bit better (hard to tell, though). In any case, FF is no longer warning me about exceeding the memory allotment for will-change. (I appreciate that FF warns me about it!)

The comment about gradients vs solid backgrounds makes sense. I often notice that the gradients have poorer performance compared to the solid backgrounds (i.e. the Pokémon with two types rather than one), especially on older devices like the Galaxy Nexus. This applies to Chrome as well as FF, though.

The innerHeight point is an interesting one. I initially wrote that optimization because I noticed it vastly improved the performance in mobile Chrome, but it's possible that it doesn't have a big or beneficial impact in Firefox.

Comment 9

[Hallvord R. M. Steen [:hallvors]]

I still don't really see issues here (now testing on a different phone).

Comment 10

[Gregory Pappas [:gregp]]

Seems fine these days