macOS: pixel-exact live-resize support

[vejeta]

What

Pixel-exact live-resize support for macOS (HiDPI/Retina), the fix for the
artifacts it exposed, and a fix for an XMMS close-time crash the differential
tests were flaking on. Rebased onto main (now including #50). Verified
end-to-end with the xwpe harness.

• Live-resize core (src/mac-live-resize.c/.h): a CFRunLoopObserver
  drives a reflow callback on each tick of Cocoa's modal resize loop, so the
  client keeps repainting while its own event loop is blocked in the drag.
  Opt-in via libx11CompatRegisterLiveResizeReflow().
• Present path (src/drawing.c, src/events.c): present during the modal
  loop, coalescing the client's repaint burst so only the final frame reaches
  the screen; re-entrancy guards prevent a nested resize loop. The observer
  skips its per-tick full-window readback when a tick produced no new content
  (no reflow, window not moving), so residual ticks after mouse-up drain
  instantly instead of queueing ~40ms redundant presents.
• Resize event routing (src/events.c, src/window.*): SDL
  RESIZED/SIZE_CHANGED -> ConfigureNotify for host-driven drags, while dropping
  the SDL echo of a client XResizeWindow (suppressSdlResizeEcho).
• Resize-increment snap (src/display.c, src/events.c/.h, src/window.*):
  replay the ICCCM size = base + i * inc quantization a real WM performs. A
  client that publishes WM_NORMAL_HINTS PResizeInc (e.g. xwpe, whose grid is
  whole font cells) has its increments cached at XSetWMSizeHints; at drag end
  snapTopLevelToResizeIncrements rounds the window DOWN to a whole increment so
  no sub-cell remainder band survives. Gated on PResizeInc, so clients that
  never set it are unaffected. The pure axis math is factored into
  libx11CompatSnapAxisToIncrement for driver-independent unit testing.
• HiDPI physical-pixel promotion (src/display.*, src/font.c,
  src/window.*, src/pointer.c): promote top-levels to physical pixels,
  scale font metrics, translate pointer coords. No-op at scale 1. The initial
  promotion prefers SDL_GetWindowSizeInPixels so the first mapped dialog
  adopts the correct cell grid instead of a logical (1x) size.
• XCopyArea clamp (src/drawing.c): clampCopyAreaSrcRect() keeps a 1:1
  blit inside the source texture bounds. Root cause of the stale function-key
  bar after resize (an Expose carrying the full sub-cell window size vs a
  back buffer snapped to a whole-cell grid).
• Mixed-DPI monitor move (src/display.*, src/events.c; xwpe WeXterm.c):
  when a window is dragged to a display with a different backing scale, the shim
  re-derives the per-window HiDPI scale and rescales the cached PResizeInc
  increments (which live in physical-pixel space) by the new/old scale ratio, so
  the drag-end snap quantises to the new monitor's cell. Handled on both the SDL2
  (SDL_WINDOWEVENT_DISPLAY_CHANGED) and SDL3 backends; xwpe reloads its Xft font
  at the new size and re-advertises WM_NORMAL_HINTS so the cell grid stays
  correct.
• Xft glyph compositing on the GPU (src/xft.c): drawUtf8String used to
  alpha-blend each glyph on the CPU (XGetImage -> blend -> XPutImage), which
  re-dirtied the pixmap readback cache and forced a full GPU->CPU readback per
  character (~78% of main-thread time while typing). It now uploads the blended
  glyph to a BLEND texture, applies the colour alpha via SDL_SetTextureAlphaMod,
  and SDL_RenderCopys onto the drawable, mirroring the core-font path -- the
  per-character readback is gone from the profile.
• XMMS teardown fix (compat/xmms-patches/0003-fix-teardown-volume-race.patch):
  cleanup_plugins() frees ip_data/op_data but the plugin-cleanup loops
  pump the GLib main loop, which dispatches the still-armed volume idle;
  read_volume then reads those freed structs and XMMS dies with its SIGSEGV
  handler (exit 1) during close. Null the globals as they are freed and let the
  volume reads short-circuit on NULL, so a late tick is a clean no-op. Closed a
  flaky xmms-window.replay assert-exit 0 failure: the crash reproduced 6/80
  under real SDL2 without the patch, 0/200 with it.
• Tests / harness: reflow-hook and resize-increment (snap_axis_to_increment)
  unit tests, a UI replay that resizes xwpe and asserts real content in the
  grown area, and the exported libx11Compat* shim ABI manifest
  (tests/shim-symbols.txt).

Upstream integration

The genuine xwpe fixes now live upstream, so this PR bumps XWPE_REVISION to
the xwpe commit that carries them and drops all compat/xwpe-patches/ (the
directory is gone; XWPE_PATCHES globs an empty set).

As clarified before, now:

1. Bump XWPE_REVISION and drop the harness patches once the fixes land
   upstream -> done.
2. Shim-only changes (e.g. the live-resize reflow hook) preserved in xwpe
   upstream rather than kept as harness patches here -> done via the bumped
   revision.
3. compat/xwpe-patches/ layout -> reworked away entirely; nothing left to
   restructure.

[vejeta]

Thanks for the review. All 16 points are addressed in 7a73e5a.

• font (HiDPI): dropped the MAX_FONT_SIZE cap on the scaled physical size; the 6x13 bitmap fallback now scales by the nearest-integer HiDPI factor so it matches the scaled core metrics.
• window-internal (bit gravity): the resize band clear/expose optimization is limited to the top-left-anchored gravities it models (NorthWest/Static); any other gravity falls back to a full-window clear/expose.
• events/pointer (dedup): scaleSdlPointToPixels is now shared via events.h, so XQueryPointer and the event path agree on rounding and scale.
• symbol coverage: make symbol-coverage now enforces the exported libx11Compat* shim ABI via tests/shim-symbols.txt (no-op where the shim isn't built).
• harness 007: only rebinds xftdraw when it was actually bound (renderer-neutral).
• harness 008: resolves the reflow hook with dlsym(RTLD_DEFAULT, ...) instead of a weak undefined symbol — portable across GNU ld and Mach-O.
• harness 012: extracted the duplicated Expose clamp arithmetic into a shared e_x_copy_backbuf_clamped() helper.

make check-unit and make symbol-coverage are green; the patch series still applies at --fuzz=0 with zero rejects.

[jserv]

1. Once the genuine xwpe fixes land upstream, should we bump XWPE_REVISION and drop the corresponding harness patches (007-010, 012)?

Yes, please go ahead.

2. Should shim-only changes (e.g. the live-resize reflow hook) live behind a configure flag in xwpe upstream, or stay as harness patches here?

Preserving changes in xwpe would be better.

3. Is the current compat/xwpe-patches/ organization the preferred long-term layout, or would you rather it be restructured?

The current patches are admittedly a bit hacky, as I am still new to XWPE. Please feel free to rework them as needed.

[vejeta]

Rebase latest main branch as #50 consolidates differential tests.

Thanks for the heads up!

This PR should now be ready for review! It took several days of testing to get this right, but I am starting to get confident that xwpe could be released in macos now with libx11-compat. I will perform some dogfooding, but will you consider making a initial release soon?

It will be very nice for the ecosystem where xwpe has been updated recently.

[vejeta]

@jserv thanks for the thorough review — all 7 points addressed, one commit each (pushed on top of the branch):

#	Comment	Commit
events.c:756	drop the in-present SDL_PumpEvents()	43136f5
events.c:801	snap only when a reflow hook is registered (hook-less clip)	4d16732
mac-live-resize.c:455	retain the cached topLeft gravity NSString (no-ARC UAF)	7726f70
mac-live-resize.c:115	keep observer-running set across the disarm decision	834a28b
drawing.c:507	read/upload each present rect once (was per-scanline)	36a33cd
display.c:879	cache resize increments from raw WM_NORMAL_HINTS writes	55e7edd
font.c:564	clamp hiDpiScaledMetric to the short range	3e54267

make check-unit and clang-format are clean, and I re-verified the live-resize drag scenarios (constant font, drag-end settle, repeated drags) on Retina after the mac-live-resize changes.

[cubic-dev-ai]

4 issues found across 35 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/mac-live-resize.c">

<violation number="1" location="src/mac-live-resize.c:106">
P1: Destroying the resized window from a reflow callback can leave `liveResizeWindow` dangling and crash on this `inLiveResize` message after the present returns. Keep an owned NSWindow reference and release it during disarm, or clear/disarm it as part of native-window teardown.</violation>
</file>

<file name="src/window-internal.c">

<violation number="1" location="src/window-internal.c:1593">
P2: Resizing a window using NorthEastGravity, CenterGravity, or another non-top-left bit gravity leaves retained pixels at the top-left, not the requested anchor. Translate the copied source/destination rect for each gravity, or consistently fall back to discarding contents for unsupported gravities.</violation>
</file>

<file name="src/drawing.c">

<violation number="1" location="src/drawing.c:301">
P2: A `clock_gettime` failure can permanently suppress presents: `beginCoalesceClientRepaint` creates a deadline from zero, but `coalesceActive` can never reach it while the clock still returns zero. Treat an unavailable clock as an inactive/expired coalesce gate.</violation>
</file>

<file name="src/font.c">

<violation number="1" location="src/font.c:1369">
P1: Core-font text becomes the wrong physical size after moving a window between differently scaled displays: the font face is opened once at a global scale, but display changes alter per-window backing scale without rebuilding that face. Track scale per drawable or recreate/invalidate affected `CompatFont` faces and text-cache entries when the target window's scale changes; do not use a stale process-global scale for this decision.</violation>
</file>

<sub>Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: Core-font text becomes the wrong physical size after moving a window between differently scaled displays: the font face is opened once at a global scale, but display changes alter per-window backing scale without rebuilding that face. Track scale per drawable or recreate/invalidate affected CompatFont faces and text-cache entries when the target window's scale changes; do not use a stale process-global scale for this decision.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/font.c, line 1369:

<comment>Core-font text becomes the wrong physical size after moving a window between differently scaled displays: the font face is opened once at a global scale, but display changes alter per-window backing scale without rebuilding that face. Track scale per drawable or recreate/invalidate affected `CompatFont` faces and text-cache entries when the target window's scale changes; do not use a stale process-global scale for this decision.</comment>

<file context>
@@ -1261,7 +1366,7 @@ Font XLoadFont(Display *display, _Xconst char *name)
         return None;
     }
-    int fontSize = requestedFontSize(name);
+    int fontSize = hiDpiScaledPixelSize(requestedFontSize(name));
     resource->ttf = TTF_OpenFont(fontEntry->filePath, fontSize);
     if (!resource->ttf) {
</file context>

[vejeta]

Deferring this to a follow-up. Per-drawable font-scale tracking is a real
enhancement, but it is a larger architectural change than the rest of this PR:
CompatFont faces and the text cache are keyed globally today, so doing this
correctly means rekeying both by target scale and invalidating/rebuilding faces
on every DISPLAY_CHANGED, plus deciding a policy for shared faces used across
windows on different displays.

In practice the multi-display core-font mis-size is also mitigated by the xwpe
side of this work (font re-derive on DPI change) and by the global-scale reset
this PR adds. I would rather land the per-drawable face tracking as its own
change with dedicated tests than fold a partial version into this PR. Filing as
a follow-up.

[cubic-dev-ai]

Agreed — the per-drawable face tracking is a separate change, and this PR’s global-scale reset plus xwpe font re-derive covers the immediate issue. I’ll keep the full rekey/invalidation work as a follow-up with dedicated tests.

[cubic-dev-ai]

P1: Destroying the resized window from a reflow callback can leave liveResizeWindow dangling and crash on this inLiveResize message after the present returns. Keep an owned NSWindow reference and release it during disarm, or clear/disarm it as part of native-window teardown.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/mac-live-resize.c, line 106:

<comment>Destroying the resized window from a reflow callback can leave `liveResizeWindow` dangling and crash on this `inLiveResize` message after the present returns. Keep an owned NSWindow reference and release it during disarm, or clear/disarm it as part of native-window teardown.</comment>

<file context>
@@ -0,0 +1,506 @@
+     * (stays YES) yet flips to NO the moment the loop exits, so we disarm
+     * exactly then instead of waiting for a possibly-delayed DidEnd
+     * notification. */
+    int stillResizing = liveResizeWindowInLiveResize();
+    if (!stillResizing) {
+        /* Modal loop has ended (DidEnd may not have posted yet). Disarm and
</file context>

[vejeta]

Deferring this to a follow-up. The concrete re-entrant use-after-free that was
reachable here (destroying the display/window from inside the reflow callback)
is already handled in this PR: XCloseDisplay defers the actual close while a
present is in flight and drains it afterward, and the observer disarm path keeps
the running latch set until after the disarm decision so both paths route
through the pending-stop handling.

Holding an owned (retained) NSWindow reference and releasing it during disarm is
a stronger invariant that also covers a client destroying the native window by
some path other than XCloseDisplay. That is worth doing, but it changes the
observer's ownership model and wants its own review; I would rather not widen
this PR's Objective-C lifetime handling further here. Filing as a follow-up.

[cubic-dev-ai]

The reachable re-entrant close is already handled in this PR by the deferred XCloseDisplay path and the pending-stop latch, so that part of the parent comment is too broad here. The retained NSWindow ownership change is a separate, stronger invariant and should go in the follow-up you mentioned.

[cubic-dev-ai]

P2: Resizing a window using NorthEastGravity, CenterGravity, or another non-top-left bit gravity leaves retained pixels at the top-left, not the requested anchor. Translate the copied source/destination rect for each gravity, or consistently fall back to discarding contents for unsupported gravities.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/window-internal.c, line 1593:

<comment>Resizing a window using NorthEastGravity, CenterGravity, or another non-top-left bit gravity leaves retained pixels at the top-left, not the requested anchor. Translate the copied source/destination rect for each gravity, or consistently fall back to discarding contents for unsupported gravities.</comment>

<file context>
@@ -1484,6 +1575,24 @@ void resizeWindowTexture(Window window)
+        int copyH = oldH < (int) windowStruct->h ? oldH : (int) windowStruct->h;
+        if (copyW > 0 && copyH > 0) {
+            SDL_Rect overlap = {0, 0, copyW, copyH};
+            SDL_RenderCopy(windowRenderer, oldTexture, &overlap, &overlap);
+        }
+    }
</file context>

[vejeta]

Deferring this to a follow-up. The retained-pixel copy here is a best-effort
optimization on top of a full Expose that repaints the window anyway, so a
non-top-left bit gravity does not lose content — it just briefly retains the
wrong pixels in the anchor region until the client redraws. The only consumer
in this stack (xwpe) uses top-left gravity, so the general case is untested in
practice.

Doing this properly means translating the source/destination overlap rect per
gravity anchor (NorthEast, Center, South, ...) and testing each, or explicitly
discarding contents for the gravities we do not model. Both are reasonable; I
would rather add the full gravity matrix with tests as a separate change than
ship a partial anchor implementation here. Filing as a follow-up.

[cubic-dev-ai]

The parent comment is too broad for this PR. The retained copy is just a temporary optimization while the full Expose repaints, and this stack only uses top-left gravity, so the non-top-left anchor case is out of scope here. A full gravity matrix can land separately with tests.

[cubic-dev-ai]

P2: A clock_gettime failure can permanently suppress presents: beginCoalesceClientRepaint creates a deadline from zero, but coalesceActive can never reach it while the clock still returns zero. Treat an unavailable clock as an inactive/expired coalesce gate.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/drawing.c, line 301:

<comment>A `clock_gettime` failure can permanently suppress presents: `beginCoalesceClientRepaint` creates a deadline from zero, but `coalesceActive` can never reach it while the clock still returns zero. Treat an unavailable clock as an inactive/expired coalesce gate.</comment>

<file context>
@@ -223,12 +277,364 @@ static void schedulePresentWake(void)
+    uint64_t deadline = coalesceDeadlineGet();
+    if (deadline == 0)
+        return False;
+    if (monotonicNowNs() >= deadline) {
+        coalesceDeadlineSet(0);
+        return False;
</file context>

Suggested change

	if (monotonicNowNs() >= deadline) {
	uint64_t now = monotonicNowNs();
	if (now == 0 || now >= deadline) {

[vejeta]

Deferring this to a follow-up, but noting it is very low risk in practice.
monotonicNowNs() is backed by SDL_GetPerformanceCounter (with a clock_gettime
fallback), which does not fail on the platforms this shim targets; a genuine
zero return would require the monotonic clock to be unavailable, at which point
coalescing is the least of the problems.

That said, treating an unavailable/zero clock as an expired (inactive) coalesce
gate is the correct defensive behavior and the suggested one-line guard is
harmless. I am grouping it with the other hardening items rather than adding it
to this already-large review batch, so it lands with a focused test for the
zero-clock path. Filing as a follow-up.

[cubic-dev-ai]

The clock-failure concern is valid, but I’m deferring it to a follow-up with a focused zero-clock test. The parent comment can stay as a hardening item, but it’s out of this batch.