1644514 - Incredible bad rendering performance on digitalocean.com hero due to Webrender display list jank

Status: RESOLVED INVALID

(Core :: Graphics: WebRender, defect)

Description

[Jens Hausdorf :jens1o [ni? me]]

Attachment: nightly-aboutsupport.json

STR:
Navigate to https://digitalocean.com.

Observe that the hero animation with the fishes feel incredibly janky, impacting site scroll performance.

Profiles:
https://share.firefox.dev/3dPY7AF
https://share.firefox.dev/3gPGQtj (older one, but it seems it's somehow better at finding out what's happening)

Please find the attached about:support output (used in the first profile in the list).

I tested the same website with Chromium, and there it is not janky at all, but a smooth animation.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

https://share.firefox.dev/2BRvUvh
Looks like a bad time in:
SVG Image drawing 5688x1600 https://www.digitalocean.com/static/bg-home-hero-3-bb4b33b77274db09b969f629ad81c4d5.svg

Comment 2

[Andrew Osmond [:aosmond] (he/him)]

I'm not sure if there is a deeper question here, but that is the size that is requested. It is a very large SVG, and we scale it up a fair bit to fit the whole background. This makes sense no?

I did realize from this code hunt that we don't apply the image.cache.max-rasterized-svg-threshold-kb pref to surfaces that bypass the cache (e.g. due to having an animation). I wrote a patch to take that into account, however 5688x1600 = 34.7 MB surface, while the threshold defaults to 200 MB, so it wouldn't clamp it anyways.

It draws at the same size in non-WebRender, so it isn't like we are doing something clever....

Comment 3

[Jeff Muizelaar [:jrmuizel]]

In this case maybe we want to be clipping it so that we only draw it as big as needed to fill element that it's the background of.

Comment 4

[Nicolas Silva [:nical]]

The website changed and we have a number of similar svg animation perf bugs on file so I'll close this one.