chore(deps): the HiDPI stack, and the frame measurement that let it land - #185
Merged
Conversation
tannevaled
added a commit
that referenced
this pull request
Aug 17, 2026
…and (#185) window v0.38.0, toolkit v0.163.0, painter v0.11.0. Three layers, each broken under the last: - painter took a stroke width and discarded it, so no border could ever be thicker than one pixel; - the toolkit's SetMetricScale, the documented HiDPI knob, was routed through by ten files out of a hundred and sixty, and Menu and Browser answered only to their own Scale field; - nothing called the knob at all, so a NativeScale window handed the widget tree twice the pixels and told it nothing. The reader threads its own scale through Scene.SetScale AND embeds toolkit widgets, so the question was whether anything would now be scaled twice. It is not, and this measures it rather than asserting it: the same frame at scale 2, rendered with the toolkit told nothing and told 2, differs in 0.17% of its pixels within one band of 54 rows -- chrome drawing its borders at the size the screen deserves, layout unmoved. A double scale would have moved a large share of the frame, two orders of magnitude away from the bound this now guards. 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
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.
windowv0.38.0,toolkitv0.163.0,painterv0.11.0 — three layers, each broken under the last:SetMetricScale, the documented HiDPI knob, was routed through by ten files out of a hundred and sixty, andMenu/Browseranswered only to their ownScalefield (toolkit#208, #209);NativeScalewindow handed the widget tree twice the pixels and told it nothing (window#50).The measurement this repo owed
The reader threads its own scale through
Scene.SetScaleand embeds toolkit widgets, so the open question was whether anything would now be scaled twice.TestReaderFrameUnderMetricScaleanswers it by rendering the same frame at scale 2 with the toolkit told nothing and told 2:One band, one widget's worth of chrome drawing its borders at the size the screen deserves, layout unmoved. A double scale would have moved a large share of the frame — which is what the test now guards, with a deliberately loose bound: it is the difference between "a border got thicker" and "the interface was laid out twice as large", and those are two orders of magnitude apart.
🤖 Generated with Claude Code