1543584 - Some SVG images cause high CPU usage when scrolling the page with Webrender enabled

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect, P1)

Description

[nayinain]

Attachment: about:support

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

1. Enable WebRender
2. Open https://www.ifanr.com/
   or https://web.archive.org/web/20190401180549/https://www.ifanr.com/
3. Scroll the page back and forth.

Actual results:

High CPU usage.

If "gfx.webrender.blob.images" is set to "false", the CPU usage of scrolling pages is normal.

Expected results:

---

Sorry for my bad English.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Here's a profile: https://perfht.ml/2P3bxhe. It looks like we're creating some very big surfaces. We need to figure out why.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Here's the prefix of the image that seems to be causing the problems: data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZG

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Attachment: Standalone version

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Attachment: Reduced test case

Comment 5

[Jeff Muizelaar [:jrmuizel]]

Setting image.cache.max-rasterized-svg-threshold-kb to -1 fixes this for me.

Comment 6

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

Attachment: Bug 1543584 - Always rasterize SVGs but clamp the maximum size.

SVG performance with the fallback path with WebRender is very bad. This
patch avoids fallback by always producing a rasterized surface we store
in SurfaceCache, but also clamping the size consistently to a configured
maximum. This will cause us to upscale rasterized SVGs which is
undesirable visually but is a lower risk change that we can uplift to
beta than fixing the underlying performance issue.

Comment 7

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

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=106fe264b9855f17288504c7e0863fbf39a59bf9

Comment 8

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

(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)

Setting image.cache.max-rasterized-svg-threshold-kb to -1 fixes this for me.

As discussed offline, this works because it tries to allocate a surface for the SVG, fails, and then it doesn't anything display at all. This will probably work better for non-WR as it will fallback to drawing the surface directly on the draw target without caching it.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3502a44129b0
Always rasterize SVGs but clamp the maximum size. r=tnikkel

Comment 10

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/3502a44129b0

Comment 11

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

Comment on attachment 9057668 [details]
Bug 1543584 - Always rasterize SVGs but clamp the maximum size.

Beta/Release Uplift Approval Request

• User impact if declined: Any page with a large vector image will be janky if the user has WebRender enabled.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce: Visit https://www.ifanr.com/. The page will not be janky.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It is a simplification of existing surface sizing logic and thus is easier to follow. We already had the logical flow of generating rasterized surfaces which don't match the requested size; now we just clamp them to a pref configurable maximum with WebRender. The user doesn't have WebRender enabled, they are unaffected, as there is an explicit check to continue with the existing behaviour.
• String changes made/needed: N/A

Comment 12

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9057668 [details]
Bug 1543584 - Always rasterize SVGs but clamp the maximum size.

P1 Webrender patch with tests, uplift approved for 67 beta 14, thanks.

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/b73974383bce

Comment 14

[Rares Doghi, Desktop QA]

Hi, I managed to reproduce this issue in Firefox Beta 67.0b13 But it no longer reproduces in our latest Beta 67.0b14 or our latest Nightly build 68.0a1 (2019-04-23). I will mark this issue accordingly.

Comment 15

[Mayank Bansal]

This massively improved bug 1135411.
Improved my score from 40s to 10s. Chrome is 11s