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

Regressions:

Improvements:

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) will be backed out in accordance with our regression policy.

For more information on performance sheriffing please see our FAQ.

Set release status flags based on info from the regressing bug 1756903

Any chance of having the side-by-side video? It's not the first time I've got a ContentFulSpeedIndex regression that happened to be an improvement (bug 1760551 for example).

Unfortunately the side-by-side doesn't work on responsiveness tests, only for the pageload ones. :(

How should I investigate more? Given there's a regression in one page and a progression in 5 I'm tempted to not dig a lot into this, but it'd be nice to confirm that it's not too worse, or that it's an instance of the metric bug mentioned in comment 2...

Wait for it... might be more alerts incoming.

(In reply to Alexandru Ionescu (needinfo me) [:alexandrui] from comment #5)

Wait for it... might be more alerts incoming.

== Change summary for alert #33870 (as of Wed, 20 Apr 2022 19:16:32 GMT) ==

Regressions:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=33870

The tp5o regressions from comment 7 appears to be holding steady - any chance you can take a look?

I'm a bit swamped with other things right now, but this code path was specific of some desktop environments; on everything but gnome/unity on X11, we were already using client decorations.

Martin, do you have a strong opinion / any idea of what might be going on there? We can back out to restore the baseline but that'd be unfortunate (and cause some glitches on the corners on GNOME+X11).

Is there any way how to run the tests locally?

I think it may be related to XWindow content sync. In CSD/X11 mode we may use two XWindows, one for toplevel window (mShell) and one for content (MozContainer) while system mode uses only one XWindow for both (mShell/MozConatiner) - MozContainer is used without XWindow. So there may be a delay in the rendering/presentation of nested MozContainer.

My ultimate goal is to remove MozContainer as windowed widget on X11 but that's a bit long term issue and needs some Wayland updates to attach wl_subsurface to mShell.

It would help to know if that's SW or HW rendering. But it looks like delayed painting, not a performance issue. Will be interesting to see if there's any video playback / WebGL rendering regression.

Alexandru, could you answer Martin's questions please? Thanks

there's no recording available for talos.

There were a few more questions from Martin:

• Is there any way how to run the tests locally?
• Is it using SW or HW rendering?

(In reply to Marco Castelluccio [:marco] from comment #14)

There were a few more questions from Martin:

• Is there any way how to run the tests locally?

https://firefox-source-docs.mozilla.org/testing/perfdocs/talos.html#running-talos-locally

• Is it using SW or HW rendering?

I think the ones that have sw in Options column use software rendering (e.g. webrender-sw) and the others hardware.