main is red: the Android-only row list never learned about the new resolution switch #385

Merged
enricobuehler merged 1 commits from worktree-console-tv-perf-safe-fixes into main 2026-08-23 09:51:02 +00:00
Owner

Follow-up to #384, which merged while the failure was still being diagnosed. main is currently failing on both the Linux (ci / rust) and Windows (windows-client / client (x64)) legs, and this is the one-line fix.

screens::settings::tests::platform_row_split_hides_only_the_other_platforms_concepts pins the exact ordered set of rows the desktop does not show — which is exactly the point of it: a row that silently changed platform is the regression it exists to catch. #384 added ReduceUiResolution as an Android-only row and updated the row count assertion beside it (44 → 45, which passed) but not this list.

left:  [… DsCapture, Controllers, ReduceUiResolution, GamepadUi, GamepadUiMode, Licenses]
right: [… DsCapture, Controllers,                     GamepadUi, GamepadUiMode, Licenses]

It slots between the Controllers action row and the console-UI switch, because it sits under Reduce motion, earlier in the Interface tab than either.

197 of 198 passed on both legs; this is the only failure, and it is a stale expectation rather than a behaviour change — nothing about which rows a platform actually shows moved. Every other check on #384 was green, including android / android, ci / rust-arm64 and ci / docs-drift.

Correction to #384's description

While chasing this I also ran the screenshot comparison that PR claimed. Its "pixel-identical" / "byte-for-byte" wording is wrong and should not be taken at face value by anyone reading the history:

  • 31 of 37 deterministic scenes differ, but the largest single-channel delta anywhere is 4/255 (under 1.6 %).
  • The aurora backdrop is byte-identical; the differences are confined to the translucent glass panels and the content drawn on them, as smooth banding contours. Nothing moved.
  • Cause: dropping the no-op save_layer removes one 8-bit intermediate composite. SrcOver is associative in exact arithmetic — the reasoning in that PR — but not in 8-bit fixed point, where every layer composite rounds.

The change is therefore visually identical and marginally more accurate (one less quantization step), not a downgrade — but it is not byte-identical, and the PR said it was.

Follow-up to #384, which merged while the failure was still being diagnosed. **`main` is currently failing** on both the Linux (`ci / rust`) and Windows (`windows-client / client (x64)`) legs, and this is the one-line fix. `screens::settings::tests::platform_row_split_hides_only_the_other_platforms_concepts` pins the exact **ordered** set of rows the desktop does not show — which is exactly the point of it: a row that silently changed platform is the regression it exists to catch. #384 added `ReduceUiResolution` as an Android-only row and updated the row *count* assertion beside it (44 → 45, which passed) but not this *list*. ``` left: [… DsCapture, Controllers, ReduceUiResolution, GamepadUi, GamepadUiMode, Licenses] right: [… DsCapture, Controllers, GamepadUi, GamepadUiMode, Licenses] ``` It slots between the `Controllers` action row and the console-UI switch, because it sits under **Reduce motion**, earlier in the Interface tab than either. 197 of 198 passed on both legs; this is the only failure, and it is a stale expectation rather than a behaviour change — nothing about which rows a platform actually shows moved. Every other check on #384 was green, including `android / android`, `ci / rust-arm64` and `ci / docs-drift`. ### Correction to #384's description While chasing this I also ran the screenshot comparison that PR claimed. Its "pixel-identical" / "byte-for-byte" wording is **wrong** and should not be taken at face value by anyone reading the history: - 31 of 37 deterministic scenes differ, but the **largest single-channel delta anywhere is 4/255** (under 1.6 %). - The aurora backdrop is byte-identical; the differences are confined to the translucent glass panels and the content drawn on them, as smooth banding contours. Nothing moved. - Cause: dropping the no-op `save_layer` removes one 8-bit intermediate composite. `SrcOver` is associative in exact arithmetic — the reasoning in that PR — but **not in 8-bit fixed point**, where every layer composite rounds. The change is therefore *visually* identical and marginally **more** accurate (one less quantization step), not a downgrade — but it is not byte-identical, and the PR said it was.
enricobuehler added 1 commit 2026-08-23 09:44:10 +00:00
test(console-ui): the Android-only row list gains the new resolution switch
ci / rust-arm64 (pull_request) Successful in 1m29s
ci / bun-nix (pull_request) Successful in 27s
ci / docs-site (pull_request) Successful in 1m17s
ci / web (pull_request) Successful in 1m54s
ci / docs-drift (pull_request) Successful in 24s
windows-client / client (arm64, --no-default-features, aarch64-pc-windows-msvc, C:\t-a64) (pull_request) Successful in 2m37s
ci / rust (pull_request) Successful in 6m54s
android / android (pull_request) Successful in 7m2s
windows-client / client (x64, , x86_64-pc-windows-msvc, C:\t) (pull_request) Successful in 6m11s
519d004cab
`platform_row_split_hides_only_the_other_platforms_concepts` pins the exact
ordered set of rows the desktop does not show, which is the point of it — a row
that silently changed platform is the regression it exists to catch. The new
switch is Android-only by design, so the expected list grows by one, between the
Controllers action row and the console-UI switch (it sits under Reduce motion,
earlier in the Interface tab than either).

Caught by CI on both the Linux and Windows legs, which run this crate's tests;
the row-COUNT assertion next to it was already updated and passed.
enricobuehler merged commit f5931650e0 into main 2026-08-23 09:51:02 +00:00
enricobuehler deleted branch worktree-console-tv-perf-safe-fixes 2026-08-23 09:51:07 +00:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: unom/punktfunk#385