With WebKit rendering directly into a wl_subsurface (#145), buffr's wgpu chrome must NOT paint opaque pixels into the browser region — otherwise it covers the subsurface entirely. Make the chrome region transparent so the WebKit subsurface shows through.
Scope
apps/buffr-app/src/render.rs:
- `wgpu::SurfaceConfiguration::composite_alpha`: pick `PreMultiplied` or `PostMultiplied` based on what the Wayland compositor advertises. Fall back to `Auto` if neither is offered. Currently `Opaque` is used.
- Verify capability via `surface.get_capabilities(adapter).alpha_modes`.
apps/buffr-app/src/main.rs (`paint_chrome_strips` + caller):
- When `supports_native()` is true: paint the BROWSER REGION as transparent (`0x00000000`). Top strip + bottom strip + overlays stay opaque.
- When false: keep current behavior (chrome composites opaque pixels into browser region for the loading anim).
`paint_chrome` already zeros the buffer at the top of each chrome_dirty paint (`render.rs` line ~956). The browser-region zeroing comes for free as long as no later code path writes into the browser rect for the supports_native=true case. The loading-anim path DOES write into the browser region; gate it on `supports_native()` so it only runs for OSR backends.
Out of scope
- Native loading anim on Wayland — gracefully no-anim during nav for v1. Could add a separate above-page subsurface for the anim later.
- Cursor over transparent regions — Wayland routes cursor based on surface, not pixel alpha; this is non-issue.
Acceptance
- WebKit subsurface visible through buffr's wgpu surface in the browser region.
- Chrome strips (statusline, tabstrip, omnibar) still opaque.
Reference
With WebKit rendering directly into a wl_subsurface (#145), buffr's wgpu chrome must NOT paint opaque pixels into the browser region — otherwise it covers the subsurface entirely. Make the chrome region transparent so the WebKit subsurface shows through.
Scope
apps/buffr-app/src/render.rs:
apps/buffr-app/src/main.rs (`paint_chrome_strips` + caller):
`paint_chrome` already zeros the buffer at the top of each chrome_dirty paint (`render.rs` line ~956). The browser-region zeroing comes for free as long as no later code path writes into the browser rect for the supports_native=true case. The loading-anim path DOES write into the browser region; gate it on `supports_native()` so it only runs for OSR backends.
Out of scope
Acceptance
Reference