Closed Bug 1543584 Opened 2 years ago Closed 2 years ago

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


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




Tracking Status
firefox67 --- verified
firefox68 --- verified


(Reporter: nayinain, Assigned: aosmond)


(Blocks 2 open bugs)



(3 files, 1 obsolete file)

Attached file 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
  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.

Blocks: wr-perf
Priority: -- → P3
Blocks: wr-67
Priority: P3 → P1

Here's a profile: It looks like we're creating some very big surfaces. We need to figure out why.

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

Attached file Standalone version (obsolete) —
Attached file Reduced test case
Attachment #9057503 - Attachment is obsolete: true
Assignee: nobody → jbonisteel
Assignee: jbonisteel → aosmond

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

Ever confirmed: true

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.

(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.

Pushed by
Always rasterize SVGs but clamp the maximum size. r=tnikkel
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

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 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
Attachment #9057668 - Flags: approval-mozilla-beta?

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.

Attachment #9057668 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

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.

QA Whiteboard: [qa-triaged]
Flags: qe-verify+

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

Blocks: 1135411
You need to log in before you can comment on or make changes to this bug.