Render radial and conic gradients as cached images
Categories
(Core :: Graphics: WebRender, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox88 | --- | fixed |
People
(Reporter: nical, Assigned: nical)
References
(Blocks 1 open bug, Regressed 1 open bug)
Details
Attachments
(13 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Currently gradients are rendered:
- conic or radial gradients: as a brush in the main pass
- linear: under some conditions they are pre-rendered in a cached render task and composited with the image brush shader (fast path), otherwise rendered directly using the linear gradient brush shader. The conditions are:
- The gradient covers the entire primitive
- It must be vertical or horizontal
- it must not have segments
The goal is for all gradients to be pre-rendered as a cached render task in all situation. The motivations for this are:
- performance: it is faster to cache the rendered gradients once and composite a simple image every frame, than to run the gradient shaders every frame, in particular for swgl
- simplify the rendering code by reducing the number of brush shader types. (Ideally we want to converge towards having only image and solid brushes in the main pass).
Assignee | ||
Comment 1•5 years ago
•
|
||
Potential solution:
Render in 3 steps:
- 1: Render the gradient stops (whatever the type) as a horizontal line in a first pass, so that the second pass doesn't have to deal with gradient stops.
- 2: in a second pass, a gradient shader samples this line to generate the image (a shader per gradient type: linear/radial/conic)
- 3: the image brush shader is used to composite the image in the main pass.
If the gradient is linear and axis aligned, we can skip step 2 (today's fast path) and stretch the gradient line from step 1 direcly when compositing.
I'm not sure how hard we need hard gradient stops to be: If there is a hard stop, is it ok to render it in step 1 and that step 2 potentially samples in between (that would creat a sort of anti-aliased transition at the hard stop)? If this is not OK, then we have to combine step 1 and 2 and have the gradient shaders deal with hard stops. The advantage of not doing that is that we can avoid requiring a variable amount of inputs in the cached render tasks even with many gradient stops: each transition between two colors can be rendered with a separate quad.
I don't see a particular reason why this would not work with segmented primitives. I suspect that the linear gradient fast path currently does not support them to avoid duplicating code but that needs to be refactored.
Assignee | ||
Comment 2•4 years ago
|
||
It is the cs_* shader used to cache linear gradients in the simple/fast path (more complex linear gradients are rendered with a brush shader. The goal of this patch series is to move all gradients to cached render tasks that will be composited with brush_image, so there will be a cs_linear_gradient introduced in a followup to cover the general case as well as cs_radial_gradient and cs_conic_gradient to replace the brush equivalents.
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
prim_store/gradient.rs is large enough that splitting it up will make things a bit clearer. The new organization is:
- prim_store/gradient/mod.rs: shared/gradient-agnostic code.
- prim_store/gradient/<linear|radial|conic>.rs: specific gradient code.
In addition, various gradient-specific data structures currently living in other modules will move into the proper gradient modules as part of this patch series.
For convenience, all specific public symbols are reexported in prim_store::gradient.
Depends on D107640
Assignee | ||
Comment 4•4 years ago
|
||
Historically WebRender's code has used 'gradient' as a shorthand for 'linear gradient' and often more specifically for 'the fast path for linear gradients'. This patch makes the naming less ambiguous in particular in places where we'll see more types of gradients sid by side introduced by upcoming patches in this series.
Depends on D107641
Assignee | ||
Comment 5•4 years ago
|
||
In the spirit of keeping primitive-specific logic mostly in the same place, this moves the linear gradient render task and the code to convert it into a gpu-visible instance into linear.rs.
I'm planning to give all specific render task structures/logic the same treatment eventually.
Depends on D107642
Assignee | ||
Updated•4 years ago
|
Comment 7•4 years ago
|
||
bugherder |
Assignee | ||
Comment 8•4 years ago
|
||
Assignee | ||
Comment 9•4 years ago
|
||
The parts stay in gradient_shared.glsl are specific to the gradient brushes, dont build without outside of the brsuh infrastructure and will be removed along with the brush gradients. The parts that go into gradient.glsl will be shared between the different gradient render task shaders.
Depends on D108464
Assignee | ||
Comment 10•4 years ago
|
||
There was a lot of trial and error in the process of making this patch, so unfortunately I didn't manage to plan it out in smaller independent steps.
This patch introduces a new cs_radial_gradient shader to use instead of the brush radial gradient shader. The gradient is produced by a cached render task and composited via the image brush.
As a bonus, tiled radial gradients now get a chance to be in the opaque pass (the previous logic was overly conservative).
Depends on D108465
Assignee | ||
Comment 11•4 years ago
|
||
Depends on D108467
Assignee | ||
Comment 12•4 years ago
|
||
Depends on D108468
Assignee | ||
Comment 13•4 years ago
|
||
Depends on D108469
Updated•4 years ago
|
Assignee | ||
Comment 14•4 years ago
|
||
Depends on D108470
Assignee | ||
Comment 15•4 years ago
|
||
Depends on D108606
Comment 16•4 years ago
|
||
Updated•4 years ago
|
Comment 17•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 18•4 years ago
|
||
Depends on D108606
Updated•4 years ago
|
Comment 19•4 years ago
|
||
Comment 20•4 years ago
|
||
Backed out 7 changesets (Bug 1687977) for causing build bustages CLOSED TREE
Failure log: https://treeherder.mozilla.org/logviewer?job_id=333755206&repo=autoland&lineNumber=13235
https://treeherder.mozilla.org/logviewer?job_id=333755187&repo=autoland&lineNumber=56987
Backout: https://hg.mozilla.org/integration/autoland/rev/80fb40ff105a6fb937bf48ec17d65b0d449f0a8b
Comment 21•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Comment 22•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/bc70dc8ad3a7
https://hg.mozilla.org/mozilla-central/rev/b88325347b88
https://hg.mozilla.org/mozilla-central/rev/0d96a981a333
https://hg.mozilla.org/mozilla-central/rev/ca611e922f49
https://hg.mozilla.org/mozilla-central/rev/cd256e69c920
https://hg.mozilla.org/mozilla-central/rev/edd376ea0b95
https://hg.mozilla.org/mozilla-central/rev/4575418fa949
Updated•4 years ago
|
Comment 23•4 years ago
|
||
== Change summary for alert #29391 (as of Tue, 23 Mar 2021 08:08:58 GMT) ==
Improvements:
Ratio | Suite | Test | Platform | Options | Absolute values (old vs new) |
---|---|---|---|---|---|
7% | microsoft | PerceptualSpeedIndex | windows10-64-shippable-qr | cold nocondprof webrender | 605.46 -> 562.33 |
6% | microsoft | FirstVisualChange | windows10-64-shippable-qr | cold nocondprof webrender | 597.83 -> 564.92 |
5% | microsoft | SpeedIndex | windows10-64-shippable-qr | cold nocondprof webrender | 599.29 -> 566.92 |
5% | microsoft | ContentfulSpeedIndex | windows10-64-shippable-qr | cold nocondprof webrender | 601.29 -> 569.58 |
5% | microsoft | PerceptualSpeedIndex | windows10-64-shippable-qr | cold nocondprof webrender | 601.12 -> 569.58 |
5% | loadtime | linux1804-64-shippable-qr | nocondprof warm webrender | 2,171.25 -> 2,071.21 | |
3% | wikipedia | fcp | linux1804-64-shippable | cold nocondprof | 1,637.44 -> 1,586.42 |
For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=29391
Nicolas, is more work needed on this bug or can it be closed now?
Assignee | ||
Comment 26•4 years ago
|
||
I did conic and radial gradients, there's still linear gradients but it's more complicated (surprisingly) and I'm focusing on other things right now. I'll change the bug title so that we can close this one.
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Description
•