Skip to content

Test: Gate the Linux parity runs on the resize rows (core-extended #139) - #253

Open
b-re-w wants to merge 9 commits into
developfrom
feat/x11-stale-present
Open

b-re-w wants to merge 9 commits into
developfrom
feat/x11-stale-present

Conversation

@b-re-w

@b-re-w b-re-w commented Oct 17, 2026 •

Copy link
Copy Markdown
Member

Closes nothing here; finishes thisisthepy/compose-multiplatform-core-extended#139.

  • Pins the fork window modules at 57b4a0e1 (newest extended), which has core-extended Feat: AT-SPI2 accessibility for the GraalVM X11 window #140 (scripted drags ask for the next size only once the last is confirmed and drawn; the cause was proven with the resize detail log: the GraalVM drag asked for 368x417 24 us after 371x416, before 371x416 was confirmed, so its frames were presented with the server already at 368x417) and Build scripts should stop with a clear error when symlinks were checked out as text #141 (both X11 windows resized through openbox and its sync counter: 39 sizes, 119 frames, stale 0, stretched 0 each).
  • PARITY_GATE="resize_stale_ratio resize_stretched" on both Linux parity runs (static-renderer.yml for Kotlin/Native, test-graalvm-renderer.yml for GraalVM): a frame at a size other than the window's, or a size without a frame, now fails the run. scripts/parity/common.sh honours it; parity-linux.test.sh checks it.
  • The Linux parity run keeps DXC_REPORT_RESIZE_DETAIL on, so the artifacts place any stale frame among the requested and confirmed sizes.

Measured on the fix (GraalVM X11 parity in this PR's earlier run): steps 60, presented 130, stale 0, stretched 0, stale_ratio 0.0000.

…etail log

Pins the fork at its instrumented branch (core-extended #139) and turns the detail log on in
the Linux parity run. Not for merging as it stands: it proves the cause first.
The instrumented branch of the fork sits on the newest extended, which also moves the
published coordinates; the probe measures the code #251 ships, so the instrumentation is
cherry-picked onto 1b3de18f.
… fix

Pins the probe at the fork fix for scripted drags (core-extended #140, cherry-picked onto the
#251 pin) and makes resize_stale_ratio and resize_stretched a gate (PARITY_GATE) on both Linux
paths: a frame at a size other than the window's, or a size without a frame, fails the run.
…sent

# Conflicts:
#	renderer/scripts/build-compose.sh
…R-3)

The newest extended, with core-extended #140 (a scripted drag asks for the next size only once
the last is confirmed and drawn) and #141 (both X11 windows resized through openbox and its
sync counter, stale 0 and stretched 0). The Linux parity runs gate on resize_stale_ratio and
resize_stretched on both paths, and keep the resize detail log for the artifacts.
@b-re-w
b-re-w marked this pull request as ready for review October 18, 2026 02:34
@b-re-w b-re-w changed the title Probe: GraalVM X11 stale presents during a resize (core-extended #139) Test: Gate the Linux parity runs on the resize rows (core-extended #139) Oct 18, 2026
@b-re-w b-re-w added the run-heavy-ci Run the heavy CI workflows on this pull request's head label Oct 18, 2026
Since core-extended #138 both GraalVM window modules name ../../scene (compile-only, for the
window surfaces runComposeWindow uses), and the project publish-window.sh writes listed
neither, so the toolchain could not read the project ("Cannot find module file in //scene")
and every renderer build on a pin past #138 stopped there. scene is listed now, and built
for the JVM alone off macOS, since its other platform is macosArm64.
…k's desktop Compose

scene compiles against the fork's Compose for the desktop, which a Kotlin/Native build (the
static Linux renderer, the Linux renderer tests) does not publish, so resolving it failed
there ("runtime-desktop:1.11.1-ext.1 ... problem"). Those builds need neither scene nor the
GraalVM window modules; they are published where the desktop Compose is, which every build
of the renderer's desktop module has.
The GraalVM macOS renderer build has the fork's desktop Compose but not its Compose for
macosArm64, and scene's macosArm64 half failed to resolve there. Nothing this renderer builds
uses that half, so scene is published for the JVM alone everywhere, edited with a sed that
both GNU and BSD take.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

run-heavy-ci Run the heavy CI workflows on this pull request's head

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant