forked from Keelrleek/SoulStream
KeelrLeek
75a95405a8
Kyle: "when clicking and dragging the window the window gets light." It did, by design that no longer had a reason: WM_ENTERSIZEMOVE parked the accent at plain BLURBEHIND for EVERY modal loop, move drags included, on the old assumption that a suspended acrylic punches through on moves the same way it does on resizes. Plain blur ignores the gradient tint and has none of the acrylic's material dimming — measured over a striped backdrop, every glass surface stepped ~15% brighter (band luma 45.5 -> 52.2) for the whole of every titlebar drag. And no compensation was possible: move loops emit no resize-drag event, the frontend never hears about them. Measured on this machine (research/glass-drag harness, SC_MOVE posted so no synthetic mouse goes near the UI, GUI_INMOVESIZE as ground truth): DWM composites the acrylic straight through a move loop. Re-asserted mid-loop it restored rest luma EXACTLY (45.5/31.8/29.4), stationary and through 28 frames of real mouse-speed motion — no punch-through, no trailing. So the swap is now gated on SIZING_LATCH: a titlebar move keeps the acrylic, a latched resize parks at Blur exactly as before (DWM genuinely suspends acrylic in live resizes — that half is load-bearing and stays). The WM_SIZING belt-and-braces arm swaps the accent too, so a resize the hit-test latch misses still degrades one mouse-move late instead of never. Verified after: entering a move loop changes nothing to the decimal; entering a resize loop still swaps (+6.7 band luma, the intended trade) and restores on release.