KeelrLeek
385b598170
Kyle reported the blur "being masked by just going opeque" on maximize, and separately the desktop punching through a maximized window. Both were the same transition, and the old guard covered neither honestly. THE GUARD'S SIGNAL IS NOW THE MODAL LOOP ITSELF. thumbbar.rs already subclasses the main window for the taskbar transport, so the size loop is three arms on that existing proc: WM_NCLBUTTONDOWN carrying a sizing hit-test (or SC_SIZE, the keyboard path) latches "this loop is a RESIZE", WM_ENTERSIZEMOVE arms, WM_EXITSIZEMOVE releases, and WM_SIZING arms as a second net because this window is undecorated and tao does its own NCHITTEST. Emitted as soulseek:resize-drag, POSTED to ourselves rather than emitted inline: emitting from inside DefWindowProc's modal loop reenters the wry runtime's window store while that loop holds it. The signal and the failure are then the same object, which is what the two previous attempts were not. The first grounded on any DOM `resize` — one event fires for a maximize, so the settled window sat flat black for ~70ms hiding glass that was already back. The second discriminated on event CADENCE, and that is the one worth remembering: on this 4-core laptop, re-rasterising every backdrop-filter at each new size pushes `resize` deliveries far apart, and measured 2026-08-28 events 150ms apart never grounded AT ALL — a real drag stayed see-through, shipping the exact artifact the guard exists to prevent. Cadence is not a proxy for the loop. DWM SUSPENDS THE ACRYLIC INSIDE THE LOOP but keeps compositing the plain BLURBEHIND, so the accent swaps down to Blur for the gesture and back on release (window_glass refactored into apply_accent + an Accent enum; GLASS_ON tracks the main window so the subclass can re-assert). The window stays glassy through a drag instead of going black — which is what Kyle actually wanted, and GROUND_DRAG is off on his verification by hand. THE MAXIMIZE ANIMATION SCALES A SNAPSHOT the accent cannot ride: measured at 43ms/frame, desktop icons read sharply THROUGH the maximized window until ~613ms after the call. Disabling the DWM zoom animation removed the punch-through outright and every frame of a ground-suppressed maximize showed the blur soft and present — but that also removed the animation, and Kyle chose the animation back with the canvas grounded across the recomposition. So transitions are forced ON, the subclass brackets the jump (active at WM_SIZE, a re-assert immediately and again at 650ms, release with the second), and GROUND_DISCRETE paints the canvas for exactly that bracket. Both policies are one-line JS constants in glass.js — flipping between "animation + dark bracket" and "instant snap + live glass" needs no rebuild. The DOM resize listener survives as the fallback for a build with no subclass, reverting to the original behaviour; it stands down for good the moment one native event is heard. Measured clean: 3 maximize/restore gestures, 3 brackets, canvas never opaque outside them; a 9-second modal loop held with zero resize events in it. 98/98 tests.