Closed Bug 1675590 (sw-wr-perf-gradient) Opened 4 months ago Closed 27 days ago

Improve radial gradient performance in swgl


(Core :: Graphics: WebRender, defect)






(Reporter: jrmuizel, Assigned: lsalzman)


(Blocks 5 open bugs)


(Keywords: perf-alert)


(3 files)

Radial gradient are always going to be hard on the CPU. We might be able to do better, but we should try to avoid having to draw them whenever possible too.

Blocks: 1674478
Blocks: 1674479
Severity: -- → S3

We don't currently have a fast path for radial gradients (or conic gradients). For linear gradients, we draw a small gradient that we persist to the texture cache. This is then drawn in the main scene as an image with the assistance of the GPU scaling / filtering hardware. We should do something similar for radial gradients. There are a few complexities with things like hard stops, but it should be easy to handle the common cases at lease.

Blocks: 1673907
Alias: sw-wr-perf-gradient

Hey Nical, Lee thought you might be able to help here once we get the texture work landed.

Flags: needinfo?(nical.bugzilla)

Keeping the needinfo as a reminder. I want to investigate bug 1681339 first (unless someone else beats me to it), I can look into this one afterward.

Blocks: 1687308
Assignee: nobody → lsalzman
Keywords: leave-open

For right now it looks like many of the test cases use 3 or more gradient stops, so writing a simple fast-path that just deals with 2-stop gradients wouldn't have helped in these situations. However, it looks like a lot of these same test-cases use transparent colors in their stops and cause us to punt to the alpha-pass shader for gradients. This alpha-pass shader does everything including clip masking, anti-aliasing, and repetitions, which is expensive if none of those features are necessary. So as an experiment I am putting up an initial patch that seems to help with some of those cases, that if a gradient was punted to the alpha-pass only because of a transparent stop, but not because of needing any of those features, it will instead revert to using the opaque shader even though there is a blend mode active, which should alleviate some of the overhead.

Pushed by
use the opaque gradient brush shader when no other features are required. r=nical
Blocks: 1677257
Pushed by
implement provisional fast-paths for linear and radial gradients. r=jrmuizel
Pushed by
avoid using alpha-pass version of gradient shader for clip-mask-only cases. r=jrmuizel

== Change summary for alert #28553 (as of Thu, 28 Jan 2021 07:09:11 GMT) ==


Ratio Suite Test Platform Options Absolute values (old vs new)
4% raptor-tp6-microsoft-firefox-cold fcp windows10-64-shippable-qr nocondprof webrender 557.83 -> 538.17
3% raptor-tp6-microsoft-firefox-cold fcp windows10-64-shippable-qr nocondprof webrender 554.25 -> 538.00

For up to date results, see:

Keywords: perf-alert

== Change summary for alert #28555 (as of Thu, 28 Jan 2021 18:52:08 GMT) ==


Ratio Suite Test Platform Options Absolute values (old vs new)
68% rasterflood_gradient linux64-shippable-qr e10s stylo webrender-sw 269.33 -> 453.17
61% rasterflood_gradient windows10-64-shippable-qr e10s stylo webrender-sw 251.08 -> 405.33
55% rasterflood_gradient macosx1014-64-shippable-qr e10s stylo webrender-sw 229.92 -> 356.58

For up to date results, see:

Blocks: 1675865

It seems that the interventions I made in this bug resulted in significant enough improvements in gradient performance that it is reasonable to close out this bug for now. It might be possible to make further improvements to gradient performance in the future if necessary via even more specialized fast-paths, but those would be better addressed as a follow-up bug rather than continuing to overload this bug.

Closed: 27 days ago
Flags: needinfo?(nical.bugzilla)
Resolution: --- → FIXED
Blocks: 1692070
You need to log in before you can comment on or make changes to this bug.