diff options
| author | srdusr <[email protected]> | 2025-03-20 16:37:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2025-03-20 16:37:00 +0200 |
| commit | 9f7744698128d7effb234eb9021b67707db3f721 (patch) | |
| tree | f62968f90279e0f1a7ee8b9b414f013547ebd69b /crates/wayland/src/udev | |
| parent | 22775f37f0adfff50f4750b657892fb33e1b2ec4 (diff) | |
| download | srdwm-9f7744698128d7effb234eb9021b67707db3f721.tar.gz srdwm-9f7744698128d7effb234eb9021b67707db3f721.zip | |
Fix border strips staying sized for a window's previous geometry
apply_geometry and restore - the Platform callbacks core's toggle_
maximize/apply_snap_zone/restore_window drive for a pure geometry
change - only called sync_geometry, never redraw_decoration_buffer.
The cached border-strip/titlebar bitmaps (self.border_top_decorations,
self.border_bottom_decorations, self.decorations) size themselves from
effective_frame, which can differ from w.geometry alone once a CSD
client's own invisible shadow margin is involved (see that function's
own doc comment) - but nothing here rebuilt them right when this
callback changed w.geometry. The next rebuild only happened whenever
this window's client next committed a frame or some other, unrelated
trigger reached redraw_decoration_buffer, not reliably right away.
Confirmed live: maximizing then restoring a Chrome window left its
border strips sized for the maximized frame while its real content had
already settled back to the smaller restored size, immediately and
permanently until some later trigger happened to catch it up - a
real, visible gap between content and border on the far (east/south)
edges, a different bug from the half-pixel corner seam fixed
separately in blend_corner_pixel.
Both apply_geometry and restore now also call redraw_decoration_buffer
right after sync_geometry, in both the udev and winit backends.
Diffstat (limited to 'crates/wayland/src/udev')
| -rw-r--r-- | crates/wayland/src/udev/platform.rs | 21 |
1 files changed, 21 insertions, 0 deletions
diff --git a/crates/wayland/src/udev/platform.rs b/crates/wayland/src/udev/platform.rs index 2868f15..96d5cf2 100644 --- a/crates/wayland/src/udev/platform.rs +++ b/crates/wayland/src/udev/platform.rs @@ -629,6 +629,25 @@ impl Platform for UdevPlatform { fn apply_geometry(&mut self, window: srdwm_core::WindowId, _geometry: srdwm_core::Rect) -> PlatformResult<()> { self.state.sync_geometry(window); + // `redraw_decoration_buffer` sizes the cached border-strip/titlebar + // bitmaps from `effective_frame`, which (see that function's own + // doc comment) can differ from `w.geometry` alone once a CSD + // client's own invisible shadow margin enters the picture. Without + // this, the bitmap stays sized from whatever it was last built at + // - correct right up until this specific call changes `w.geometry` + // (`toggle_maximize`/`apply_snap_zone`, the two core-side callers of + // this callback) - and the *next* rebuild only happens whenever + // this window's own client next commits (`protocols/compositor.rs`'s + // per-commit call) or something else unrelated triggers one, not + // reliably right away. Confirmed live: maximizing then restoring a + // Chrome window left its border strips sized for the *maximized* + // frame while its real content had already settled back to the + // smaller restored size, immediately and permanently until some + // later unrelated trigger (a fresh commit) happened to catch it up + // - a real, visible gap between content and border on the far + // edges, not the half-pixel seam `blend_corner_pixel`'s own fix + // addressed. + self.state.redraw_decoration_buffer(window); Ok(()) } @@ -660,6 +679,8 @@ impl Platform for UdevPlatform { fn restore(&mut self, window: srdwm_core::WindowId) -> PlatformResult<()> { self.state.sync_geometry(window); + // See `apply_geometry`'s own doc comment - same gap, same fix. + self.state.redraw_decoration_buffer(window); Ok(()) } |