test(visual): ROI-mask screenshots to eliminate clock and chrome drift#28
Merged
Conversation
3 tasks
afonsojramos
added a commit
that referenced
this pull request
May 12, 2026
…rift (#31) ## Summary Continuous-improvement step on the visual ROI work. The remaining drift after #28 was 5/14 platforms showing ~1-2% pixel jitter, driven by anti-aliasing at the cyan→yellow boundary line inside the window and the magenta/green checker against macOS's translucent menu bar. This PR replaces the window content with solid blocks of color: - **Old**: 200x100 split horizontally — cyan (top) / yellow (bottom). A subpixel AA seam where the colors meet jittered between runs. - **New**: 200x100 white background with a centered solid 80x40 black rectangle. No AA inside the rectangle (pure white-to-white). One sharp AA boundary at the inner square edge, but that's between two solid colors with no transparency, so it should render deterministically. Tray icon stays as the magenta/green checker — it's the *backdrop* (macOS menu bar translucency) that causes its drift, which is unfixable without redesigning the icon altogether. Detection logic moved from "global cyan+yellow pixel count" to "white+black pixel count *inside* the reported `window.getBounds()` rect", which also stops OS chrome white/black text from contributing false-positives. Thresholds: ≥5000 white + ≥500 black inside the rect (out of an expected ~16800 + ~3200 fully visible). ## Test plan - [ ] All 14 visual jobs pass with the new detection - [ ] After merge: auto-refresh PR diff shrinks from 5 → 0-1 platforms (or close to it) - [ ] Saved screenshots show a white "frame" where the window is (the inner black square blends with the black mask background — that's fine, the frame is the visual cue)
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
1 participant
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.
Summary
Even after #22, #25, and #26, the auto-refresh PR keeps reopening every push because residual clock/dock/wallpaper drift survives time-pinning on some platforms (macOS menu bar clock, Linux MATE/Tint2 panels, Windows taskbar clock). Suppressing every clock source per-OS is whack-a-mole; this PR sidesteps it by masking the saved screenshot to only the rects we care about.
showWindow(), emitVISUAL:bounds={"tray":{...},"window":{...},"scale":N}withmb.tray.getBounds(),mb.window.getBounds(), and the primary display's scale factor for DIP→physical-pixel conversion.tray.getBounds()returns{0,0,0,0}), then mask the on-disk PNG to keep only the tray + window rects (with 4px padding) and write the masked version. Everything outside — clock, dock, wallpaper, pre-launched File Explorer — becomes solid black.Auto-refresh PR diffs from here on out should only fire when the actual tray icon or popover window rendering changes, not when the OS clock ticks.
Test plan
mainafter merge → auto-refresh PR diff is empty or close to it