Issue 345: picom is the first suspect, the graphics stack, and compositing off as the first test

The operator reports picom leaving a chat window stale after a workspace switch before, never recorded.
The diagnosis now names the graphics stack, puts picom first among the candidates, and makes the first
step at the next empty reminder turning compositing off, which loses nothing; a Betterbird restart comes
after, refused while a message is being written unless the operator says yes.

04-ISSUES/345-a-reminder-window-shows-transparent-and-empty/00-report.md

@@ -20,6 +20,13 @@ The operator's view of done: *on the workstation, when an Outlook meeting is due
 shows the meeting (title, time, Dismiss/Snooze) on a normal background, not a transparent empty window,
 and the mesh has tools to see and fix Betterbird.*
 
+## Reported history
+
+The operator reports (2026-10-09) earlier trouble with picom on the workstations, never recorded: a chat
+window (Telegram) froze, not redrawn, after a change of i3 workspace. `records_search` for picom finds
+nothing about it. It is the same kind of failure as this one, a window the compositor shows without its
+content, and it makes picom the first suspect here.
+
 ## Why it is an issue
 
 Two gaps, and the symptom itself.
@@ -51,4 +58,7 @@ The diagnosis is in [01-diagnosis.md](01-diagnosis.md).
   through the module's setting, its log, restart, check, and a reminder on demand from a throw-away
   profile, so a fix can be proved without touching the operator's calendar.
 
+- The `picom` module's backend and damage tracking become settings of each machine (defaults unchanged:
+  `glx`, `use-damage` true), so the candidate fixes can be set and proved without a hand edit.
+
 What is not done: the cause, and so the fix. See the diagnosis.

04-ISSUES/345-a-reminder-window-shows-transparent-and-empty/01-diagnosis.md

@@ -46,6 +46,12 @@ file with one event whose reminder was due 30 to 40 seconds after the start. Fou
 Each image was taken from the whole screen at the window's place and looked at. Every Betterbird window
 on the workstation has depth 32 (an ARGB visual), the long-running one's mail window included.
 
+**The graphics stack** (2026-10-09, read on the workstation; no mesh tool answers it yet, so it was read
+with the login shell's command verb): an AMD Radeon RX 6950 XT (Navi 21) on the kernel's `amdgpu` driver,
+the X server's `amdgpu` driver (`xf86-video-amdgpu` 25.0.0) on X.Org 1.21.1.24, Mesa 26.2.4 (`radeonsi`),
+kernel 7.2.8, picom 13. picom runs with the `glx` backend, vsync, fading, and damage tracking at picom's
+default (on).
+
 **The screenshot tool's failure.** `xorg_screenshot` of the whole screen worked; of one window it
 dumped the window by its id (`xwd -id`): that is the call reported failing with BadColor, and here it
 answered BadWindow for a window that had just closed.
@@ -60,25 +66,41 @@ answered BadWindow for a window that had just closed.
 - **Not the preferences found.** The operator's theme and colour switch drew the reminder correctly in
   a fresh process (run 3). The preference that would take away the alpha visual does not change the
   depth in this version (run 4), so it is no lever.
-- **Candidates not yet ruled out:**
-  1. the long-running process: five days of uptime, with WebRender's per-window state recreated many
+- **Candidates not yet ruled out, the first suspect first:**
+  1. **picom.** The operator has seen picom leave a window stale after a workspace switch before (the
+     reported history). picom's `glx` backend with vsync and damage tracking on (its default) is a known
+     source of windows left unpainted or stale on some drivers: picom repaints only the regions it was
+     told changed, and a missed damage event leaves a window's area as it was, for a new window empty.
+     That fits a reminder that appears while the operator is on another workspace. Not yet seen
+     happening;
+  2. the long-running Betterbird: five days of uptime, with WebRender's per-window state recreated many
      times (its thread names count to 15). A fresh process drew every reminder;
-  2. Owl's reminders, which the test cannot raise without the operator's account;
-  3. the moment it appears: a reminder raised while a full-screen window holds the focused workspace
+  3. Owl's reminders, which the test cannot raise without the operator's account;
+  4. the moment it appears: a reminder raised while a full-screen window holds the focused workspace
      (Slack and a game were full screen on the day), or on the right-hand monitor where it was saved.
 
 ## What would decide it
 
-At the next real reminder, before touching it:
+At the next real reminder that shows empty, before touching it:
 
 1. `xorg_windows` with class `Calendar` on the workstation: the window's map state and depth.
 2. `xorg_screenshot` with that window and `inline`: what the screen shows.
-3. `betterbird_status`: how long the process has run.
+3. **`picom.picom_toggle` with `on` false: compositing off.** If the reminder's content appears, picom is
+   the cause. This needs no restart of Betterbird and loses nothing. `xorg_screenshot` again, then
+   `picom_toggle` with `on` true to put compositing back.
+4. Only if the content does not appear with compositing off: `betterbird_status` (how long it has run),
+   then `betterbird_restart`. It refuses while a composer window is open, because the unsent message
+   would be lost; `discard_unsent` is given only on the operator's yes. Then `betterbird_reminder_test`
+   with `carry` of the theme shows whether a fresh process draws it.
 
-If the window is mapped and empty, `betterbird_restart` (which also sends its output to the journal,
-so the next failure leaves a trace) and `betterbird_reminder_test` with `carry` of the theme show
-whether a fresh process draws it. If it does, candidate 1 holds, and the fix is in Betterbird or in its
-renderer, not in the mesh; a preference to try then (`gfx.webrender.software` true, declared through the
-module's setting) is proved with the same test before the operator relies on it.
+**If picom is the cause**, the candidate fixes are the `picom` module's settings for that machine, never a
+hand edit: `use-damage` false first (repaint the whole screen each frame), else `backend` `xrender`. Each
+is proved on the workstation before the operator relies on it: set it, `picom_restart`, raise a reminder
+with `betterbird_reminder_test` while on another workspace, switch back, and look with `xorg_screenshot`.
+The reported chat-window freeze is checked the same way.
+
+**If a fresh Betterbird draws it and picom is not the cause**, the fix is in Betterbird or its renderer, not
+the mesh; a preference to try then (`gfx.webrender.software` true, declared through the `betterbird`
+module's setting) is proved with the same test.
 
 Until then this record stays `diagnosing`, and the acceptance sentence is not met.