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

VERIFIED FIXED in Firefox 67

Status

()

defect
P1
normal
VERIFIED FIXED
a month ago
28 days ago

People

(Reporter: nayinain, Assigned: aosmond)

Tracking

(Blocks 3 bugs)

unspecified
mozilla68
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox67 verified, firefox68 verified)

Details

Attachments

(3 attachments, 1 obsolete attachment)

Reporter

Description

a month ago
Posted 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 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.

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

Here's a profile: https://perfht.ml/2P3bxhe. 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

Posted file Standalone version (obsolete) —
Posted 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.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee

Comment 6

a month ago

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.

Assignee

Comment 8

a month ago

(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

a month ago
Pushed by aosmond@gmail.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3502a44129b0
Always rasterize SVGs but clamp the maximum size. r=tnikkel

Comment 10

a month ago
bugherder
Status: ASSIGNED → RESOLVED
Last Resolved: a month ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Assignee

Comment 11

a month ago

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
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]

Comment 14

29 days ago

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.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+

Comment 15

29 days ago

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.