Open Bug 1606631 Opened 5 years ago Updated 24 days ago

Inefficient z-ordering of elements in the browser UI, causes large layers with current WebRender heuristics


(Firefox :: Theme, defect, P3)




Performance Impact pending-needinfo
Tracking Status
firefox73 --- affected


(Reporter: mstange, Assigned: mstange, NeedInfo)


(Depends on 1 open bug, Blocks 2 open bugs)


(Keywords: perf:resource-use, Whiteboard: [wr-planning])


(6 files)

Steps to reproduce:

  1. Be on macOS.
  2. Enable the prefs gfx.webrender.all, gfx.webrender.compositor (requires restart), and gfx.core-animation.tint-opaque (restartless).
  3. Pay attention to the amount of redness on the screen.

Expected results:
The active tab and the back button should be drawn into the same red layer as the rest of the chrome.

Actual results:
The active tab and the back button are drawn into another red layer that goes on top of the rest of the chrome. When the statusbar appears (when a link is moused over), there's a big red layer that covers the majority of the browser window.

Most of the browser chrome is "behind" the content area, in z-order. Elements that are "in front" of the content area, in z-order, go into a separate layer. (The fact that these elements don't overlap the content area is not taken into account by WebRender, and we should keep it that way.)

We should apply some z-index declarations in browser CSS, so that we have the following order:

  1. Bottom layer: The window background and all elements in the browser chrome that do not overlap the content area. This should include the active tab and the back button.
  2. Middle layer: The <browser> for the tab contents
  3. Top layer: Elements from the browser chrome that can overlap the tab contents, such as the focused URL bar and the URL bar autocomplete dropdown.
Component: Site Permissions → Theme
Attachment #9118342 - Attachment description: Bug 1606631 - Ensure that elements in the browser chrome are not split into multiple WebRender OS layers unnecessarily, by grouping elements behind and in front of the content area. r=ntim → Bug 1606631 - Use CSS variables to create a centralized list of z-index values in the browser window, and make sure that the content area is in front of the active tab. r=Gijs, r=dao
Whiteboard: [fxperf]
Whiteboard: [fxperf] → [fxperf:p3]
Whiteboard: [fxperf:p3] → [fxperf:p3][wr-planning]
Whiteboard: [fxperf:p3][wr-planning] → [wr-planning] [fxperf:p3]
Blocks: wr-80
No longer blocks: wr-80

Would there be a way to write an automated test that ensures this won't regress?

Probably. I'm still working out whether it actually works reliably... there's evidence that the combination of Retained Display Lists and WebRender's layerization algorithm don't handle z ordering the way we want and that just setting the right z-indexes won't reliably achieve the intended optimization.

@Markus: Should this block mac release?

Flags: needinfo?(mstange.moz)
Blocks: wr-mac
No longer blocks: wr-mac-nightly
Depends on: 1771974
Severity: normal → S3
Flags: needinfo?(mstange.moz)
Performance Impact: --- → ?
Whiteboard: [wr-planning] [fxperf:p3] → [wr-planning]

Is this bug still valid?

Flags: needinfo?(mstange.moz)
Performance Impact: ? → pending-needinfo
You need to log in before you can comment on or make changes to this bug.