test: accept the four Windows antialiasing snapshots - #47
Merged
eliotmcintire merged 1 commit intoSep 4, 2026
Merged
Conversation
Issue_20;_arr_working0Win.png 4 px changed Issue_32_Plot_factors_lower_case_id0Win.png 1 px changed Issue_32_Plot_factors_lower_case_id2Win.png 1 px changed Issue_32_Plot_factors_lower_case_id4Win.png 1 px changed Seven pixels out of 1,920,000, max channel delta 58/255, and in every case the changed pixels sit inside a text glyph -- a glyph of the plot title `maps$forestAge` for Issue 20, the legend label `A` for the three Issue 32 images. No mark, axis, colour ramp or raster cell moved. This is the windows-latest runner's font rasteriser rounding an antialiased edge differently than it did when the references were recorded. Taken from run 33899141206, which produced byte-identical renders on all four Windows legs (release, devel, oldrel-1, oldrel-2), so one accepted set clears all four. The same bytes also came back from runs 33779375229 and 33897686977, i.e. the new rendering is stable, not a flake. expect_snapshot_file() compares PNG bytes exactly, so a one-pixel change in a font rasteriser is indistinguishable from a real regression. A custom `compare =` with a small per-pixel budget would keep the signal and drop this class of failure; not attempted here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011kpoQV6nNqcknk16R3RzBB
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.
Accepts the last four failing reference images. With #45 and #46 merged, these are all that stand between
developmentand a fully green matrix.Issue_20;_arr_working0Win.png:765Issue 20; arr workingmaps$forestAgeIssue_32_..._id0Win.png:793rainbow paletteAIssue_32_..._id2Win.png:793green rampAIssue_32_..._id4Win.png:812cols = "Reds"A7 pixels out of 1,920,000. No mark, axis, colour ramp or raster cell moved — this is the
windows-latestrunner's font rasteriser rounding an antialiased edge differently than it did when the references were recorded.Provenance
Taken from run 33899141206, which produced byte-identical renders on all four Windows legs (release, devel, oldrel-1, oldrel-2), so one accepted set clears all four. The same bytes also came back from runs
33779375229and33897686977— the new rendering is stable, not a flake.Worth doing separately
expect_snapshot_file()compares PNG bytes exactly, so a one-pixel change in a font rasteriser is indistinguishable from a real regression, and this will recur every time the runner image updates its fonts. A customcompare =with a small per-pixel budget would keep the signal and drop the whole class. Not attempted here.🤖 Generated with Claude Code
https://claude.ai/code/session_011kpoQV6nNqcknk16R3RzBB