fix(sdl2): apply Linux desktop scaling to window size and UI scale - #54
Closed
FarnaHerry wants to merge 1 commit into
Closed
fix(sdl2): apply Linux desktop scaling to window size and UI scale#54FarnaHerry wants to merge 1 commit into
FarnaHerry wants to merge 1 commit into
Conversation
What: On Linux, derive the desktop scaling factor from SDL display DPI (quantized to 0.25 steps, 1.25x minimum), enlarge newly created windows by that factor, and use it as the dpiScale fallback when the drawable-to-window ratio is 1.0. Why: SDL drawables on Linux (X11 and Wayland) never reflect desktop scaling, so the SDL2 backend computed a dpiScale of 1.0 and rendered unscaled, physically smaller UI than GLFW builds on HiDPI desktops. GLFW reads the desktop content scale directly; Windows was already handled via GetDpiForWindow; macOS reports a 2.0 drawable ratio. How: Add core::window::displayScaleEstimate() sharing the display-DPI quantization, multiply the SDL_CreateWindow size by it on Linux, and fall back to it in the app entry point's dpiScale() so logical layout size, rendering scale, and pointer mapping stay consistent.
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
2 participants
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.
What
On Linux, derive the desktop scaling factor from SDL display DPI (quantized to 0.25 steps, 1.25x minimum), enlarge newly created SDL windows by that factor, and use it as the
dpiScalefallback when the drawable-to-window size ratio is 1.0.Why
SDL drawables on Linux (X11 and Wayland) never reflect desktop scaling — the drawable size always equals the window size. The SDL2 backend therefore computed a
dpiScaleof 1.0 and rendered unscaled, physically smaller UI than GLFW builds on HiDPI desktops (e.g. 2x Wayland sessions). GLFW builds scale correctly because GLFW reads the desktop content scale directly; Windows was already handled viaGetDpiForWindow; macOS reports a 2.0 drawable ratio.How
core::window::displayScaleEstimate(), which quantizesSDL_GetDisplayDPI-derived scale to 0.25 steps and ignores values below 1.25x (avoids false positives from physical EDID-reported DPI on unscaled displays).createWindow(Linux SDL2 only), multiply the requested window size by that estimate so the buffer covers the same physical area as other backends.dpiScale(), keep the drawable ratio as the primary source (macOS Retina) and fall back todisplayScaleEstimate()so logical layout size, rendering scale, and pointer mapping stay consistent.Testing
Verified on Fedora 44 (Wayland session, 2x desktop scaling, Xft.dpi=192) with all four backend combinations (OpenGL/Vulkan × GLFW/SDL2):
galleryand other examples in SDL2 builds now show the same physical window size and UI scale as GLFW builds, with native crispness (GLFW via XWayland is compositor-upscaled and slightly blurrier).ctestresults unchanged on all four builds: 19/20 passing.Note: the single failing test,
shadertoy_runtime_probe, already fails on the basedevbranch (introduced by c404bdeperf(render): cache static siblings, fails identically on all four backend builds) and is unrelated to this change.