diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/TODO.md | 8 |
1 files changed, 8 insertions, 0 deletions
diff --git a/docs/TODO.md b/docs/TODO.md index 257dd56..5c055cb 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -13,6 +13,14 @@ that has the full story. Keep this list current as items close or open; update the source doc's own entry too, don't let this drift into a second stale copy the way `PANEL_SUPPORT_TODO.md` did. +## Real bug, confirmed live, not yet root-caused: a window's border/decoration briefly shows clipped/missing after a cross-monitor tiling move, self-correcting on a later redraw (2026-08-26) + +Reported live: "the border/window looks cut offed when moved from one monitor to another". Confirmed directly, not just reported - moved a real window (`srd dispatch move window <id> right`) from `HDMI-A-1` (scale ~0.843) to `eDP-1` (scale 1.0) and screenshotted immediately after: the window's left border was entirely missing and its content sat flush against the screen edge (the page's own heading read "...UNK" instead of "TYPERPUNK", clipped). A second screenshot of the same window a couple of minutes later showed a complete, correctly-bordered window - the same window, same position, self-corrected. + +Working hypothesis, not confirmed: `crates/srdwm/src/main.rs::sync()` calls `apply_geometry`/`redraw_decoration` for every visible window synchronously, every dirty tick, immediately after `arrange_workspace` - so the border rebuilds from the compositor's own already-updated model (`w.geometry`) with no apparent lag on that side. But `redraw_decoration`'s own frame calculation (`effective_frame_of`) corrects against the *client's* real committed size, which needs an actual `configure` -> client resize -> commit round-trip to catch up - normally fast enough to be invisible, but a cross-*monitor* move between different scales asks the client to resize by more than a same-monitor tiling swap ever would, plausibly widening that window enough to actually see. + +Not fixed this pass - reliable reproduction via `srd dispatch move window` turned out to be inconsistent (its "left"/"right" semantics swap within a monitor's own tiling order as often as they cross monitors, state-dependent in a way that isn't fully understood yet either), and a live mouse-drag (the gesture the user actually described) can't be synthesized from this environment to test directly. Not a corruption risk regardless - this session's own earlier defensive `src`-crop clamp (the resize-lag fix, see below) already bounds every border/titlebar crop against the decoration buffer's real last-built size, so the failure mode here is "briefly shows a stale/incomplete frame," never an out-of-bounds read. Next step, if picked back up: either synthesize the exact multi-window cross-monitor retile that reproduced it once, or add targeted diagnostic logging around `redraw_decoration`/`effective_frame_of`'s own inputs across a live-tested restart. + ## Real bug, root-caused and fixed, jointly with a peer session (dotfiles-16): layer-shell surfaces on a fractionally-scaled output were unclickable and, for a bottom/right-anchored one, never painted at all (2026-08-26) Reported live in stages: "AGS isn't even working fast/seems weird now on this monitor even", "dock and AGS buttons aren't working in the other monitor". The peer session independently instrumented AGS itself (both bar and dock report `win_visible=true realized=true reveal=true overlapped=false` on the affected output - the client is asking for the right thing) and srdwm's own `layer_hit_test` log, and found the dock received zero hits across ~40 minutes while the same output's wallpaper and bar took hundreds - full findings in their own `docs/PANEL_SUPPORT_TODO.md`/`SESSION_HANDOFF.md` in the `rust-rewrite` worktree. |