Scrolling Slack mesage history is very laggy when using SWGL and the quad conic gradient shader
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr115 | --- | unaffected |
firefox124 | --- | unaffected |
firefox125 | --- | unaffected |
firefox126 | --- | fixed |
firefox127 | --- | fixed |
People
(Reporter: cpeterson, Assigned: nical)
References
(Blocks 2 open bugs, Regression)
Details
(Keywords: perf:responsiveness, regression)
Attachments
(1 file)
I see a serious performance regression when trying to scroll Slack message history when using SWGL in Nightly 126.0a1 build 2024-04-04 on Windows. (I voluntarily use 32-bit Firefox builds and enable gfx.webrender.software = true to help dogfood SWGL, since I figure few other Nightly users will use 32-bit or SWGL.)
I tried bisecting the regression using mozregression, but the performance difference is not as obvious in a clean profile (still using SWGL), but a Firefox profile of my main profile (https://share.firefox.dev/3U5CfZN) shows a lot of CPU time spent in ps_quad_conic_gradient
functions, so I'm guessing this is a regression from your fix for "Port conic gradients to the quad shaders" bug 1887837.
Updated•7 months ago
|
Assignee | ||
Comment 1•7 months ago
|
||
Ah, snap. I forgot to re-add the swgl fast path for radial gradients before landing.
Assignee | ||
Comment 2•7 months ago
•
|
||
Edit: Nevermind, radial gradients have a fast path but conic gradients dont. The regression comes from them not being cached anymore.
Comment 3•7 months ago
|
||
Setting Fx126 to Fixed sicne the regressor was backed out of central
https://bugzilla.mozilla.org/show_bug.cgi?id=1887837#c6
Assignee | ||
Comment 4•7 months ago
|
||
Slack uses the following full -screen conic gradient:
{
prim_rect: Box2D((0.0, 0.0), (3840.0, 1927.0))
center PointKey { x: 1920.0, y: 963.00024 },
ConicGradientParams { angle: 0.7853982, start_offset: 0.0, end_offset: 1.0 },
stops: [
GradientStop { offset: 0.0, color: ColorF { r: 0.79607844, g: 0.8, b: 0.8117647, a: 1.0 } },
GradientStop { offset: 0.25, color: ColorF { r: 0.91764706, g: 0.91764706, b: 0.91764706, a: 1.0 } },
GradientStop { offset: 0.5, color: ColorF { r: 0.79607844, g: 0.8, b: 0.8117647, a: 1.0 } },
GradientStop { offset: 0.75, color: ColorF { r: 0.91764706, g: 0.91764706, b: 0.91764706, a: 1.0 } },
GradientStop { offset: 1.0, color: ColorF { r: 0.79607844, g: 0.8, b: 0.8117647, a: 1.0 } }
]
}
Picture caching does not help as the scrollable part is not promoted to its own layer for some reason.
Pretty sad. Maximized on a 4k screen, We get to chose between a terribly expensive but barely visible (if at all, I can't see it) primitive drawn every frame or wasting 29MB of RAM (and memory bandwidth each frame) on said primitive.
Assignee | ||
Comment 5•7 months ago
|
||
Bug 1891543 helps quite a bit by making sure all of the conic gradient pixels we can occlude are occluded. However a lot of the backgrounds in slack aren't fully opaque so there is still a pretty large amount of conic gradient pixels and does not make perf good enough without caching.
Assignee | ||
Comment 6•7 months ago
|
||
[task 2024-04-23T08:57:24.036Z] 08:57:24 ERROR - error: unused variable: `data_handle`
[task 2024-04-23T08:57:24.036Z] 08:57:24 INFO - --> gfx/wr/webrender/src/prepare.rs:233:52
[task 2024-04-23T08:57:24.036Z] 08:57:24 INFO - |
[task 2024-04-23T08:57:24.037Z] 08:57:24 INFO - 233 | PrimitiveInstanceKind::ConicGradient { data_handle, .. } => {
Assignee | ||
Updated•7 months ago
|
Comment 10•7 months ago
|
||
bugherder |
Comment 11•7 months ago
|
||
Description
•