Fix border/decoration stuck at a stale size after a passive tiling reflow

effective_frame_of sized a window's border/shadow/titlebar from
dwindow.geometry() - xdg_surface::set_window_geometry. Per smithay's
own implementation that value is the client's cached hint intersected
with bbox(), falling back to bbox() only if never set. Nothing in the
protocol obliges a client to resend the hint on every resize, and
intersection() can never return something larger than its smaller
operand - so once a client's cached hint is smaller than its current
real buffer, geometry() stays clamped there permanently.

Confirmed live: after a passive tiling reflow (this window resized
only as a side effect of a sibling window moving, no direct action on
this window itself), Firefox's real content filled the correct, much
larger area immediately, but its border/decoration stayed rendered at
a small fraction of that - unchanged for several seconds, well past
both animation settling and any reasonable commit-throttle window --
until an unrelated maximize/restore cycle happened to prompt Firefox
into resending a fresh hint and self-correcting.

Switched to bbox(): the real bounding box of the window's current
surface tree, which updates on every commit unconditionally. This
gives up excluding a CSD client's own invisible drop-shadow margin,
but sync_geometry already unconditionally sends all four tiled state
bits specifically so a compliant client (GTK4/Firefox) reserves no
such margin at all, so a compliant client loses nothing. Both the
decoration-bitmap sizing (redraw_decoration_buffer) and the render
loops' own border/shadow/occlusion positioning funnel through this one
function, so they stay consistent with each other - avoiding the
out-of-bounds texture-crop regression a previous, different attempt at
this same lag hit (see this function's own doc comment history).

0 files changed, 0 insertions, 0 deletions