The built-in font follows the metric scale too - #216
Merged
Conversation
The audit measures chrome and not text -- deliberately, since a centred baseline rounds and type carries its own scale -- and that left a gap it could not see. A host that turned the one documented HiDPI knob got padding, borders and controls at twice the size around type that stayed exactly as it was. Not a partial improvement: a worse interface than the one it had before it asked. activeFont is now nil until a host sets one, and nil means "the built-in bitmap at the current metric scale" rather than "the built-in bitmap at 1". A font the host chose is left alone, because a host that chose a font chose its size -- the same rule Menu and Browser already follow for their own Scale fields, and the same reason: one scale, set in one place, never applied twice. The bitmap is a block rasteriser, so the scale rounds to a whole multiple: 1.4 draws the plain font and 1.6 the doubled one, because half a block is not a glyph. The scaled font is cached, since text is measured per glyph per frame and allocating one each time would be a new object sixty times a second. 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.
The metric audit measures chrome, not text — deliberately, since a centred baseline rounds and type carries its own scale. That left a gap it could not see: a host that turned the one documented HiDPI knob got padding, borders and controls at twice the size around type that stayed exactly as it was. Not a partial improvement — a worse interface than the one it had before it asked.
The rule, which the toolkit already had
activeFontis now nil until a host sets one, and nil means "the built-in bitmap at the current metric scale" rather than "the built-in bitmap at 1". A font the host chose is left alone, because a host that chose a font chose its size.That is the same rule
MenuandBrowserfollow for their ownScalefields (#209), and for the same reason: one scale, set in one place, never applied twice.SetFontuntouchedSetFont(NewBitmapFont(3))MetricScale() == 1MetricScale() == 2The bitmap is a block rasteriser, so the scale rounds to a whole multiple: 1.4 draws the plain font and 1.6 the doubled one, because half a block is not a glyph. The scaled font is cached — text is measured per glyph per frame, and allocating one each time would be a new object sixty times a second.
🤖 Generated with Claude Code