fix(x11): correct XDBE swap presentation on Xwayland (font thickening + frame repeat)

[tmineno]

Two related fixes for XDBE double-buffering under Xwayland (and drivers where XdbeBackground is unreliable). Found while running conky as an X11 client on GNOME/Mutter + NVIDIA.

1. Back buffer not cleared -> fonts thicken (ec9bc11)

In the XDBE path clear_text() is a no-op and the back buffer is only ever reset via the XdbeBackground swap action. Some drivers don't honor it (notably under Xwayland and certain NVIDIA setups); the back buffer then keeps the previous frame, so antialiased glyphs blend on top of themselves and fonts appear to thicken over time -- most visibly when other windows overlap conky and trigger extra redraws.

Fix: clear the back buffer explicitly with XFillRectangle after the swap, mirroring the existing XPMDB path.

2. Deferred swap -> momentary frame repeat (b3e0409)

The swap was left in the X output buffer and flushed lazily. Under Xwayland the compositor can coalesce/reorder it with later requests and momentarily re-present the previous frame -- a visible "frame repeat" (e.g. a clock's seconds bouncing back, 40 -> 39 -> 40, at the boundary).

Fix: XSync after the swap so the server processes it before conky proceeds, giving a clean, ordered present. A plain XFlush only queues the request and is not enough (verified empirically: XFlush still bounces, XSync does not).

Blast radius

• X11 output with double_buffer = true on XDBE builds only. XPMDB builds, Wayland output, and double_buffer = false are unchanged.
• On drivers where XdbeBackground already works, the explicit clear is a redundant reset (identical output).

Testing

Verified on Xwayland + Mutter (GNOME) + NVIDIA with an ARGB (semi-transparent) own_window_colour and double_buffer = true: no font thickening on overlap, no frame-repeat at the second boundary.

[netlify]

✅ Deploy Preview for conkyweb canceled.

Name	Link
🔨 Latest commit	9105dbb
🔍 Latest deploy log	https://app.netlify.com/projects/conkyweb/deploys/6a12a73dfc2f2d0008887e2c

[Caellian]

How does XPMDB work for you?

I'm asking because XPMDB path is much closer to how Wayland side works and also how most GUI toolkits handled double buffering on X11 (not relying on Xdbe ext - even though now it's always provided). I was hoping to remove one or the other and make it so that X11 just uses Cairo if it's included the same way Wayland does (pipeline unification), after Cairo rendering backend is up-to-speed of course.

[tmineno]

@Caellian Tested it — built with -DBUILD_XDBE=OFF to exercise use_xpmdb on the same box (Xwayland + Mutter + NVIDIA, ARGB own_window_colour, double_buffer = true).

• Font thickening: none. XPMDB already clears the back buffer every frame (the path fix fix imap message count updates #1 mirrors), so nothing accumulates.
• Flicker: XPMDB isn't immune — I had to (1) XSync instead of XFlush after the present, and (2) drop the dirty-region clip so the whole window is copied each frame (XDBE's swap already presents the whole window; a partial copy leaves the rest of Xwayland's reallocated buffer blank). With both, it's solid.

XPMDB's copy-to-window model maps better onto the Wayland/Cairo path, so +1 on consolidating there. I've added both fixes to the XPMDB path in this PR.

[tmineno]

Correction to "solid": longer soak shows a rare residual blank-frame flicker, and it's on the XDBE path too (the shipped build with both fixes) — so not XPMDB-specific. Whole-window present and XSync cut the rate; dropping the server-side background didn't help further, and none of it fully eliminated the flicker; two different present paths (Xdbe swap vs pixmap copy) showing the same symptom puts the cause below X11, in Xwayland's async surface-commit → compositor-present. (Couldn't cross-check via native Wayland output — out_to_wayland hard-requires wlr-layer-shell, which Mutter doesn't implement.) So XPMDB ≈ XDBE here; fully eliminating it likely needs the Wayland/Cairo present path.

[Caellian]

Here's a patch for Mutter that adds wlr-layer-shell. I don't use it, so I never tested it - only that it compiles and looks somewhat reasonable (Claude output).

If you go with it, match the version you already have on your system and apply the patch on top. It might yield better or worse results depending on how extensively you're using conky (cairo backend is not complete).