From baabd91411dacd179c690f724b6cbfe6270cb131 Mon Sep 17 00:00:00 2001 From: srdusr <99972264+srdusr@users.noreply.github.com> Date: Tue, 5 May 2026 14:10:00 +0200 Subject: 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. --- docs/TODO.md | 49 +++++++++++++++++++++++++++++++------------------ 1 file changed, 31 insertions(+), 18 deletions(-) diff --git a/docs/TODO.md b/docs/TODO.md index e6f95f8..04ccbdb 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -30,19 +30,34 @@ challenged. Their generalisation is the useful part and it applied here immediately: a "blocked" is a measurement and it decays, and two commands failing is two commands failing, not proof that the space is empty. -**The seam check itself is still not done, and here is exactly where it -stopped.** With the split working, a floating window was placed with its -right edge exactly on the seam and the pixels just past it sampled: no -shadow, correctly. But the negative control failed - the same window off -the seam had no shadow either, so the test proved nothing. Running both -clients in one instance settled why: Alacritty renders a shadow in a capture -(a real measured gradient, 24 -> 27 -> 32 -> 35 -> 36 over ~24px), and Nemo -renders none, with `shadows: true`, both floating, in the same instance, -regardless of which is focused. Nemo is server-side decorated and Alacritty -is not, which is a lead and not a conclusion - it has not been root-caused -and is recorded here rather than guessed at. Finishing the seam check needs -either that answer or a shadow-rendering client that can be positioned onto -a seam (Alacritty has no titlebar to drag). +**The seam check is done, and the "SSD versus CSD" lead recorded here first +was wrong.** With the split working, the first attempt looked like a pass -- +window's right edge on the seam, no shadow past it - but the negative +control failed: the same window off the seam had no shadow either, so it +proved nothing. Running both clients in one instance narrowed it to +"Alacritty gets a shadow, Nemo does not", and decorated-versus-CSD was +written down as the lead. + +One temporary diagnostic in the build path settled it in a single run, and +it was neither: `max=true`. Nemo restores its own maximized state on +startup, and the shadow gate correctly excludes a maximized window (it has +no neighbour to separate from). There was no bug and decoration had nothing +to do with it. Recorded because the lead was stated here as a lead and has +to be retracted in the same place - one log line beat two rounds of +reasoning from symptoms. + +With Nemo un-maximized the real A/B ran, 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. + +So `shadow_rect_clipped` does what its tests say it does, on screen, and the +monitor-seam bleed the owner reported as "windows show a bit in the other +monitor" is confirmed fixed rather than only unit-tested. One real inconsistency was found and fixed on the way: the winit capture pass measured the shadow from `w.geometry` while both on-screen loops @@ -257,11 +272,9 @@ the fragment list is clipped. Six tests, built on the incident's own numbers (two 1920x1080 outputs, seam at x=1920): flush against the seam from either side, straddling it, mid-monitor, the desktop's outer edge, and no monitors at all. -**Not confirmed on screen** - and the reason first given for that was -wrong. See the correction entry at the top of this file: monitor split works -in a nested instance now, so the seam itself is reproducible; what is still -missing is a window that both renders a shadow and can be positioned onto -the seam. +**Confirmed on screen** - see the correction entry at the top of this file +for the measurement (a real 24px shadow falloff where there is no seam, and +nothing at all past the boundary when the window's edge sits on it). Correcting the entry below, which called this moot because the user had turned shadows off: `srd settings` against the live session reports -- cgit v1.2.3