Tell the toolkit what a point is worth (#49) - #50
Merged
Conversation
A back-end honouring NativeScale hands the widget tree a framebuffer at the panel's own resolution. The tree lays out in those pixels, so unless something tells it that a point is now two of them, every padding, radius, border and control stays at its logical size and the interface comes out half as large on the sharpest screens. Window crisp, UI tiny -- worse than not having asked. toolkit.SetMetricScale is the documented knob for exactly this, and nothing called it: across window, toolkit and the reader the only callers were two lines of a toolkit test. The back-end is the only party that knows the scale, so the back-end sets it -- at the point where each one learns it. X11 at bring-up, Wayland when the compositor says which screen the surface is on (and again when it changes), Windows and macOS in Open. Only when the caller asked for NativeScale. A window that never asked leaves the setting alone, which is asserted: it is process-wide, and an application that was not thinking about DPI must not find its metrics doubled because something else in the binary was. Safe to set now that toolkit v0.163.0 has ONE scale: Menu and Browser defer to the global instead of answering only to their own field, so a host that sets both is not scaling anything twice. Measured, not assumed. A reader frame rendered at scale 2 with the toolkit told nothing, and again with it told 2, differs in 0.17% of its pixels, in a single band of 54 rows: chrome drawing its borders at the size the screen deserves, with the layout unmoved. A double scale would have moved a large share of the frame. The measurement lives in the reader as a guard. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
tannevaled
added a commit
that referenced
this pull request
Aug 17, 2026
A back-end honouring NativeScale hands the widget tree a framebuffer at the panel's own resolution. The tree lays out in those pixels, so unless something tells it that a point is now two of them, every padding, radius, border and control stays at its logical size and the interface comes out half as large on the sharpest screens. Window crisp, UI tiny -- worse than not having asked. toolkit.SetMetricScale is the documented knob for exactly this, and nothing called it: across window, toolkit and the reader the only callers were two lines of a toolkit test. The back-end is the only party that knows the scale, so the back-end sets it -- at the point where each one learns it. X11 at bring-up, Wayland when the compositor says which screen the surface is on (and again when it changes), Windows and macOS in Open. Only when the caller asked for NativeScale. A window that never asked leaves the setting alone, which is asserted: it is process-wide, and an application that was not thinking about DPI must not find its metrics doubled because something else in the binary was. Safe to set now that toolkit v0.163.0 has ONE scale: Menu and Browser defer to the global instead of answering only to their own field, so a host that sets both is not scaling anything twice. Measured, not assumed. A reader frame rendered at scale 2 with the toolkit told nothing, and again with it told 2, differs in 0.17% of its pixels, in a single band of 54 rows: chrome drawing its borders at the size the screen deserves, with the layout unmoved. A double scale would have moved a large share of the frame. The measurement lives in the reader as a guard. 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.
Closes #49.
A back-end honouring
NativeScalehands the widget tree a framebuffer at the panel's own resolution. The tree lays out in those pixels, so unless something tells it that a point is now two of them, every padding, radius, border and control stays at its logical size and the interface comes out half as large on the sharpest screens. Window crisp, UI tiny — worse than not having asked.toolkit.SetMetricScaleis the documented knob for exactly this, and nothing called it: acrosswindow,toolkitand the reader, the only callers were two lines of a toolkit test.Where
The back-end is the only party that knows the scale, so the back-end sets it — at the point where each one learns it:
Xft.dpiis readOpenOnly when the caller asked for
NativeScale. A window that never asked leaves the setting alone, which is asserted: it is process-wide, and an application that was not thinking about DPI must not find its metrics doubled because something else in the binary was.Why it is safe to set now
toolkit#209 (v0.163.0) gave the toolkit one scale:
MenuandBrowserhad their ownScalefield and answered only to it, so a host that set both risked scaling twice. The field now replaces the global rather than falling back to 1.Measured, not assumed
The thing #49 said had to be measured first. A reader frame rendered at scale 2 with the toolkit told nothing, and again with it 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 — two orders of magnitude apart, which is why the guard is a loose bound and not a golden image. The measurement lives in the reader as a permanent test (go-news-reader/reader).
🤖 Generated with Claude Code