cocoa: the live damage proof X11 and Wayland had and this backend did not - #118
Merged
Merged
Conversation
… not Incremental present on macOS now draws only the changed ROWS, each run wrapped as a bitmap of its own. That makes the row arithmetic load-bearing in a way it was not before: an off-by-one, or two bands that fail to meet, leaves a stale line across a window that nothing later repairs, because the framebuffer persists between frames. The unit tests hold the arithmetic; nothing held the pixels. A four-quadrant root is presented, one quadrant is changed, and ONLY its rectangle is presented. The window is then photographed through the window server — screencapture -l, not -cacheDisplayInRect:, since that asks the view to draw itself afresh, takes the whole-buffer fallback, and would prove nothing about the banded path. The changed quadrant must have changed and the other three must be untouched. Two things are said in the file rather than left to be discovered: Colours are compared between the two captures, never against the bytes that were written. The window server colour-manages what it composites: a buffer holding pure red photographs as (234,51,36) here, so absolute colours would measure the display profile instead of the present path. And the proof's own limit, found by breaking the code on purpose. A band read from the wrong SOURCE rows is caught. A band drawn at the wrong DESTINATION is NOT: AppKit redraws the window for its own reasons between the change and the photograph, that redraw takes the whole-buffer fallback, and it repairs the evidence. TestBandDest and its seam case fail on that ablation, which is where that guarantee actually lives. Captures go through captureDir — outside any repository, somewhere durable — which this package already had. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Incremental present on macOS now draws only the changed rows, each run
wrapped as a bitmap of its own (#117). That makes the row arithmetic
load-bearing in a way it was not before: an off-by-one, or two bands that fail
to meet, leaves a stale line across a window that nothing later repairs,
because the framebuffer persists between frames.
The unit tests hold the arithmetic. Nothing held the pixels —
TestLiveX11Damageand
TestLiveWaylandDamageexist, and there was no Cocoa counterpart.What it does
A four-quadrant root is presented, one quadrant is changed, and only its
rectangle is presented. The window is then photographed through the window
server and the two captures are compared: the changed quadrant must have
changed, the other three must be untouched.
screencapture -l, not-cacheDisplayInRect:— that asks the view to drawitself afresh, which is an AppKit-initiated draw, takes the whole-buffer
fallback, and would prove nothing about the banded path.
Two things said in the file rather than left to be discovered
Colours are compared between the two captures, never against the bytes that
were written. The window server colour-manages what it composites: a buffer
holding pure red photographs as
(234,51,36)on this display, so absolutecolours would measure the display profile instead of the present path.
The proof's own limit, found by breaking the code on purpose. A band read
from the wrong source rows is caught. A band drawn at the wrong destination
is not: AppKit redraws the window for its own reasons between the change
and the photograph, that redraw takes the whole-buffer fallback, and it repairs
the evidence.
TestBandDestand its seam case fail on that ablation, which iswhere that guarantee actually lives. A live proof that heals itself is worth
saying out loud rather than trusting.
Housekeeping
Captures go through
captureDir— outside any repository, somewhere durable —which this package already had.
Gated behind
darwin && integration+WINDOW_COCOA_INTEGRATION=1, like therest of the live suite, and it skips rather than fails if Screen Recording is
not granted.
🤖 Generated with Claude Code