diff options
| author | srdusr <[email protected]> | 2026-05-05 14:10:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2026-05-05 14:10:00 +0200 |
| commit | baabd91411dacd179c690f724b6cbfe6270cb131 (patch) | |
| tree | 55c9c883de9647c955a36da8097d0ab763ddc2e6 /crates/core/src/manager | |
| parent | 790ee906957b8b855dfc23cf1b206628585fd1ec (diff) | |
| download | srdwm-baabd91411dacd179c690f724b6cbfe6270cb131.tar.gz srdwm-baabd91411dacd179c690f724b6cbfe6270cb131.zip | |
Confirm the monitor-seam shadow fix on screen, and retract a wrong lead
The seam bleed the owner reported as "windows show a bit in the other
monitor" was fixed and unit-tested but never seen. With monitor split now
working in a nested instance it can be, and it is.
Same window, same settings, same instance, same scanline. Control, right
edge at x=320 with no seam nearby: a real shadow, (9,9,13) two pixels out,
fading through (11,11,17) and (12,12,19) to the bare desktop (13,13,20) by
23px, a full 24px falloff. Seam, right edge exactly on the boundary at
x=640: (13,13,20) at every sample from two pixels out onward. Nothing
crosses.
Retracting the "SSD versus CSD" lead recorded in the previous commit. The
first attempt at this test looked like a pass until the negative control
failed - the same window off the seam had no shadow either. Narrowing it to
"Alacritty gets a shadow, Nemo does not" pointed at decoration, and that was
written down as a lead. It was neither: one temporary diagnostic in the build
path reported max=true. Nemo restores its own maximized state on startup and
the shadow gate correctly excludes a maximized window, which has no
neighbour to separate from. No bug, and decoration had nothing to do with
it. One log line beat two rounds of reasoning from symptoms; the lead is
retracted in the same file that stated it.
515 tests pass, clippy clean.
Diffstat (limited to 'crates/core/src/manager')
0 files changed, 0 insertions, 0 deletions