feat: Optimise window show time OS-20603#121
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces BrightSign-focused Chromium/Electron patch updates to reduce Wayland window “show” latency by switching hide/show to opacity-based behavior while ensuring the compositor continues producing frames and that window-level opacity/position changes propagate correctly.
Changes:
- Keep Chromium compositing/tiling/raster active for “window-level” effect nodes even when opacity is 0.
- Fix Wayland window-level opacity so it survives frame playback and applies to both root + subsurfaces.
- Refine Wayland position-only bounds updates to commit window geometry without triggering buffer reallocation delays.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| patches/chromium/fix_wayland_window_call_setwindowgeometry_for_position_updates.patch | Updates Wayland to commit geometry on position-only changes to avoid frame/buffer churn. |
| patches/chromium/fix_brightsign_window-level_opacity_not_applied_via_zcr_blending_v1.patch | Adds window-level opacity plumbing (GetWindowOpacity + multiplication during frame playback) and blending enforcement for effective opacity. |
| patches/chromium/feat_brightsign_keep_compositing_active_for_window-level_zero.patch | Prevents EffectTree from marking window-level nodes “not drawn” when opacity is 0, avoiding raster restart delays. |
| patches/chromium/.patches | Registers the two new Chromium patches in the patch application list. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| + // Window-level opacity set via SetOpacity(). Applied to the root surface | ||
| + // during frame playback by multiplying into the per-frame config opacity. | ||
| + float window_opacity_ = 1.0f; |
There was a problem hiding this comment.
The comment says the window-level opacity is applied only to the root surface, but in this patch the opacity is multiplied into config.opacity inside WaylandFrameManager::ApplySurfaceConfigure() for every surface (root and subsurfaces). Update this comment to match the actual behavior so future readers don’t assume subsurfaces are unaffected.
| + // from the per-frame overlay config opacity and is multiplied into the root | ||
| + // surface opacity during frame playback. |
There was a problem hiding this comment.
This doc comment says the window-level opacity is multiplied into the root surface opacity, but the patch applies the multiplication in ApplySurfaceConfigure() for both the root surface and all subsurfaces. Adjust the wording to reflect that it applies across all surfaces of the window.
| + // from the per-frame overlay config opacity and is multiplied into the root | |
| + // surface opacity during frame playback. | |
| + // from the per-frame overlay config opacity and is multiplied into the | |
| + // opacity applied to the root surface and all subsurfaces during frame | |
| + // playback. |
d2d6641 to
14d1e34
Compare
Description of Change
The changes in this PR are optimisations to reduce the time for doing a show from ~180ms on series 5 and ~60ms on series 4 to about 10ms. The result is that we are now inline with QtWebEngine.
The two main changes that result in this optimisation are:
Another issue was found that when the opacity is set to 0 at a wayland surface level the opacity is still set to 1. This results in the plane assignment code to assign a plane for the transparent (hidden window). This has been fixed using patch fix_brightsign_window-level_opacity_not_applied_via_zcr_blending_v1.patch, together with a small fix in the Weston compositor.
Finally, it was found that the way the code in patch fix_wayland_window_call_setwindowgeometry_for_position_updates.patch had been done can result in wayland buffers being destroyed and recreated, which adds a delay. The patch has been updated with an improved change to achieve the same thing.
Checklist
npm testpassesRelease Notes
Notes: