From 61d01bb79c6882c950f45a1176ba1f30fbbd4824 Mon Sep 17 00:00:00 2001 From: srdusr <99972264+srdusr@users.noreply.github.com> Date: Sat, 9 Aug 2025 00:57:00 +0200 Subject: Fix interactive-resize border/shadow lag without the OOB risk that sank the first attempt effective_frame_of now returns the live drag target while a window is being interactively resized (same change as the reverted first attempt), but two things make it safe this time instead of reintroducing the out-of-bounds texture sample that reversion was for: - Every src crop rect built from a window's frame width in udev/render.rs and winit/render.rs (titlebar, top border strip, bottom border strip) is now clamped against DecorationSignature's own recorded width/ border_width - the bitmap's actual last-built size - before reaching MemoryRenderBufferRenderElement::from_buffer, which does not itself validate src against the real texture size. This is a structural floor independent of timing, not a repeat of the previous unsafe approach. - handle_pointer_position now calls redraw_decoration_buffer once per resize motion event (throttled to 60Hz via a new CompState::resize_redraw_at), closing the lag at its source instead of only catching up on the next real client commit. This also fixes the shadow bitmap's identical commit-vs-live-position gap for free, since redraw_decoration_buffer rebuilds all three bitmaps together. Updates the TODO.md entry for this bug with the full before/after. --- crates/wayland/src/state/mod.rs | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'crates/wayland/src/state/mod.rs') diff --git a/crates/wayland/src/state/mod.rs b/crates/wayland/src/state/mod.rs index a3e9b1a..0ef4346 100644 --- a/crates/wayland/src/state/mod.rs +++ b/crates/wayland/src/state/mod.rs @@ -417,6 +417,20 @@ pub(crate) struct CompState { /// own blanket call, which never actually checked whether this /// specific window was one of the windows that triggered the tick. pub(crate) decoration_signatures: HashMap, + /// When `handle_pointer_position` last called `redraw_decoration_buffer` + /// for the window currently being interactively resized - throttles + /// that call to once per `RESIZE_REDRAW_INTERVAL` (see `input::pointer`), + /// since a pointer + /// can emit motion events far faster than a titlebar's text and border + /// bitmaps are worth re-rasterizing. Without this the decoration buffer + /// only catches up with `effective_frame_of`'s now-live resize geometry + /// (see that function's own doc comment) once the drag ends and the + /// blanket `sync()` redraw runs - correct, but visibly laggy borders + /// for the whole drag. `None` whenever no resize is in progress; reset + /// there rather than left stale, so a *new* resize's first motion event + /// always redraws immediately instead of inheriting a stale timestamp + /// from a previous drag. + pub(crate) resize_redraw_at: Option, /// Which titlebar button (if any) the pointer is currently over, on /// which window, and *when that hover started* - set from `handle_ /// pointer_position`'s own `hit_test` result, read by `redraw_ -- cgit v1.2.3