win32: the system UI font at the monitor's DPI, not DEFAULT_GUI_FONT - #170
Merged
Merged
Conversation
Every control was set in DEFAULT_GUI_FONT, the stock object that still answers "MS Shell Dlg" -- Tahoma at 8 points -- while the message font every Windows app has drawn its controls in since Vista is what NONCLIENTMETRICS carries (Segoe UI at 9 points, or the user's choice). And a stock font never scales: the backend declares itself per-monitor DPI aware, so on a 150% monitor nothing scaled it and every label drew at 96-DPI size. w32_ui_font_for_dpi answers SystemParametersInfoForDpi's message font, cached per DPI; the eight WM_SETFONT sites, the tab strip's bold base, apply_font's base (a custom size is now in points at the window's DPI) and the vg metrics face go through it. WM_DPICHANGED re-fonts every widget under the window and lays the stacks out again.
# Conflicts: # backend/aether_ui_win32.c
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.
A design-quality fix for Windows: every control was set in
DEFAULT_GUI_FONT, the stock object that still answers "MS Shell Dlg" — Tahoma at 8 points, the face of 2001 — while the message font every Windows app has drawn its controls in since Vista is whatNONCLIENTMETRICScarries (Segoe UI at 9 points, or whatever the user chose in Accessibility). A stock font also never scales, and the backend declares itself per-monitor DPI aware (v2), so on a 150% monitor Windows scaled nothing for it and every label drew at 96-DPI size.w32_ui_font_for_dpi(dpi):SystemParametersInfoForDpi(SPI_GETNONCLIENTMETRICS)'slfMessageFont(Windows 10 1607+; pre-1607 the system-DPI metrics scaled), cached per DPI, outliving every window.w32_ui_font(hwnd)picks the window's monitor DPI (GetDpiForWindow), the system's while the widget is on the hidden holder.WM_SETFONTsites, the tab strip's bold base,apply_font's base (a customfont_sizeis now points at the window's DPI, fromGetDpiForWindow, notGetDeviceCaps), and the vg text-metrics face go through it.WM_DPICHANGED(w32_refont_tree): every widget under the window in the font at the new DPI — one with a size, weight or face of its own re-derived from the new base — then every stack laid out again, since every text just changed its measure.Before/after on this box (system: Segoe UI 9pt, 96 DPI) —
themes_demo, screen grabs: the Tahoma face with its squared letterforms and tighter em dashes, then Segoe UI. Verified natively: runtime test, 74 headless driver specs identical to main, 13 on-screen specs (typography, tables, lists, tabs, splits, weight clamp, themes, frames) pass.Not in this PR, filed as a follow-up: the fixed pixel defaults in
measure_widget(fields 140×26, progress 140×16, textarea 200×80, button/label padding) do not scale with DPI either.