2020981 - 39.23 - 4.23% bing-search FirstVisualChange + 12 more (Android, OSX) regression on Mon February 23 2026

Status: NEW

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

Description

[Treeherder Bug Filer]

Perfherder has detected a browsertime performance regression from push 3d8bc17e5a132d0615371d688e5360feafd37dd9. As author of one of the patches included in that push, we need your help to address this regression.

Please acknowledge, and begin investigating this alert within 3 business days, or the patch(es) may be backed out in accordance with our regression policy.

Regression	Test	Platform	Options	Absolute values [old vs new]	Performance Profiles
39%	bing-search FirstVisualChange (doc)	macosx1470-64-shippable	bytecode-cached cold fission webrender	169.00 -> 235.29	Before/After
39%	yahoo-mail FirstVisualChange (doc)	macosx1470-64-shippable	cold fission webrender	215.06 -> 298.78	Before/After
35%	yahoo-mail ContentfulSpeedIndex (doc)	macosx1470-64-shippable	cold fission webrender	238.23 -> 321.82	Before/After
35%	yahoo-mail SpeedIndex (doc)	macosx1470-64-shippable	cold fission webrender	241.30 -> 324.96	Before/After
30%	bing-search ContentfulSpeedIndex (doc)	macosx1470-64-shippable	bytecode-cached cold fission webrender	343.50 -> 445.80	Before/After
28%	bing-search ContentfulSpeedIndex (doc)	macosx1470-64-shippable	cold fission webrender	339.07 -> 434.03	Before/After
23%	bing-search SpeedIndex (doc)	macosx1470-64-shippable	bytecode-cached cold fission webrender	425.05 -> 523.23	Before/After
21%	bing-search SpeedIndex (doc)	macosx1470-64-shippable	cold fission webrender	427.90 -> 518.62	Before/After
16%	bing-search PerceptualSpeedIndex (doc)	macosx1470-64-shippable	bytecode-cached cold fission webrender	437.64 -> 508.98	Before/After
5%	bing-search-restaurants ContentfulSpeedIndex (doc)	android-hw-a55-14-0-aarch64-shippable	cold webrender	756.81 ms -> 793.56 ms
5%	bing-search-restaurants FirstVisualChange (doc)	android-hw-a55-14-0-aarch64-shippable	cold webrender	742.96 ms -> 778.97 ms
4%	bing-search-restaurants PerceptualSpeedIndex (doc)	android-hw-a55-14-0-aarch64-shippable	cold webrender	803.20 ms -> 838.20 ms
4%	bing-search-restaurants SpeedIndex (doc)	android-hw-a55-14-0-aarch64-shippable	cold webrender	815.94 ms -> 850.47 ms

Support & Actionable Steps

For questions, please contact [e-mail]. You can also find help on Slack (#perf-help) or Matrix (#perftest).

Action guide details:

• See the guide to handling regression bugs for investigation steps.
• Review the alert summary for affected tests, graphs, and comparisons.
• Check the PerfCompare results.
• Tests on Try: Run all tests using ./mach try perf --alert 48856 (See documentation link for details).
• Profiling jobs: Trigger jobs from Treeherder job view or request them from [e-mail].

Comment 1

[Nicolas Silva [:nical]]

I am looking into this but my understanding is that mac CI is so backed up that I probably won't get any profiling data in the next few days. We suspect that it may be related to shader caching. If so the good news is that we are in a transition period where more shader are being used while porting code over to a new system that will ultimately have fewer shaders so it would then likely be a win in the near future.

Comment 2

[Donal Meehan [:dmeehan]]

Fx150 goes to beta next week.
:nical, any updates on the investigation here? Wondering if we can expect a fix in time for Fx150

Comment 3

[Nicolas Silva [:nical]]

I am confident at this point that this is caused by shader compilation at startup on a cold cache. Two things are affecting this test negatively right now:

1. We are using (and therefore compiling) more shaders for this test case right now.

2. The new gradient shader is heavier than the old one (so it takes longer to compile).

3. one will naturally resolve itself as I continue transitioning WebRender from one shading system to the other (the fact that we are in the middle of the transition is what's causing the number of shaders to be up). Towards the end we should have fewer shaders than we had before the beginning of the transition so it should be better overall. How much this affects content depends on what's on the page. For example we moved the functionality of 6 shaders into one, so if the page was using a mix of radial, conic and linear gradients with and without transparency we have a net win, whereas if the page only has a mix of linear gradients (some of which are falling back to the old code path), then we are compiling more shaders.

4. Requires work that we haven't planned for in the coming months. I am not sure how much this is affecting the issues versus the number of shaders. We could investigate other ways to evaluate gradient stops in shaders, or we could work around shader compilation times on mac and android by either moving away from OpenGL (so that shader caching works like on other platforms) or start triggering shader compilation in the background asynchronously at startup instead of waiting for the first frame. All of these are a fair amount of work, some of it we aspire to get to but haven't committed to yet.

For now we'll have to take the regression and hope that bug 2020923 and other dependencies of bug 1887835 will gradually make things better and hopefully even turn the regression into an improvement. I am pretty optimistic about it but also the regression is content-specific, appears to affect a small part of the user base (mostly x86 macs for the big (>5%) changes if I understand correctly), and there are improvements in between the regressions that are as significant so I am not worried about letting it ride the train.