Here's a breakdown of the key themes discussed in the Hacker News thread about UI scaling.
Wayland vs. X11 for UI Scaling
A central theme revolves around the historical and current state of UI scaling in X11 versus Wayland. Several users debated whether X11 was inherently incapable of achieving good scaling or whether it was simply a matter of where development efforts were focused.
- "Many of these problems could have been solved in X11 with additional effort, and some even made it to partial solutions available. The community simply chose to put its energy into bringing it all together in the Wayland stack instead." - sho_hn
- One user questions if there was any formal analysis showing X11 couldn't be extended to meet modern UI scaling demands: "I cannot recall, was there any paper analyzing why working and almost working X11 features do not fit, few additional X11 extensions cannot be proposed anymore and another solution from scratch is inevitable." - kvemkon
- sho_hn clarified that the decision to move to Wayland wasn't based on formal impossibility proofs for X11 but on a pragmatic assessment of where development resources would be most effective. "Did the community decide that after a long soul-seeking process that ended with a conclusion that things were impossible to make happen in X11, and does that paper you invoke exist? No, not really." - sho_hn
- denkmoon asserts that multi-monitor mixed DPI setups do not work well on X11: "Multi monitor with mixed DPIs absolutely does not work well in x11 in 2025." - denkmoon
- To which kelnos replies that "It could, though. GTK has support for mixed DPI, just only for Wayland. There's no reason why it couldn't work on X11. It might be more tricky to get right, but it's just a matter of work." - kelnos
Fractional Scaling Implementation and Quality
The discussion delved into the technical details of fractional scaling, particularly the approaches used in Wayland and other systems like macOS.
- pedrocr criticized the "draw at 2x scale and then scale down" approach, arguing that it leads to performance loss and blurry output. "That's probably better than most scaling done on Wayland today because it's doing the rendering directly at the target resolution instead of doing the "draw at 2x scale and then scale down" dance that was popularized by OSX and copied by Linux. If you do it that way you both lose performance and get blurry output." - pedrocr
- kccqzy noted that macOS initially used 2x scaling without downscaling because the hardware was designed for it and that experimenting with non-integer scaling led to buggy results in early versions of macOS.
- pedrocr stated that fractional scaling, when implemented correctly, should allow UI elements to snap to pixel boundaries, avoiding blurriness, regardless of the scaling factor. It was also asserted that current web browsers ARE currently (mostly) capable of doing this, but are not being allowed to do it.
- sho_hn replied that fractional scaling in KDE Plasma does snap to the pixel grid: "What you want is exactly how fractional scaling works (on Wayland) in KDE Plasma and other well-behaved Wayland software: The scale factor can be something quirky like your 1.785, and the GUI code will generally make sure that things nevertheless snap to the pixel grid to avoid blurry results, as close to the requested scaling as possible. No "extra window system transforms"." - sho_hn
- pedrocr explains his concern with the way integer scaling is communicated in current Wayland: "And even in integer scaling things like events are sent to clients in virtual coordinates instead of just going "here's your NxM buffer, all events are in those physical coordinates, all scaling is just metadata I give you to do whatever you want with" - pedrocr
- zokier stated, regarding fractional scaling, "All major compositors support fractional scaling extension these days which allows pixel perfect rendering afaik, and I believe Qt6 and GTK4 also support it." - zokier
DPI vs. Scaling Factor: User Experience and Technical Considerations
A significant portion of the discussion explored the merits of using DPI (dots per inch) versus a relative scaling factor for managing UI size across different displays.
- cycomanic questions the switch to scale factors rather than using DPI as a fitting metric: "That's great, however why do we use a "scale factor" in the first place? We had a perfectly fitting metric in DPI, why can't I set the desired DPI for every monitor, but instead need to calculate some arbitrary scale factor?" - cycomanic
- sho_hn responds that using scaling factors is more approachable for non-technical users. "Typically they have a slider from 100% to, say, 400% and let you set this to something like 145%. This may take some getting used to if you're familiar with DPI and already know the value you like, but for non-technical users it's more approachable. Not everyone knows DPI or how many dots they want to their inches." - sho_hn
- cycomanic argues that a relative scaling factor (where the reference is device-dependent) is a bad design and will confuse users who want consistent UI sizes across multiple monitors.
- sho_hn acknowledges the validity of cycomanic's point but notes that different form factors and viewing distances often mean users don't want to strictly match DPI across displays.
- zokier defends scaling factors arguing "Basically scale factor neatly encapsulates things like viewing distance, user eyesight, dexterity, and preference, different input device accuracy, and many others. It is easier to have human say how big/small they want things to be than have gazillion flags for individual attributes and then some complicated heuristics to deduce the scale." - zokier
- MadnessASAP notes that not all displays accurately report their DPI, making scaling factor a more practical metric at the protocol level: "Not all displays accurately report their DPI (or can, such as projectors). Not all users, such as myself, know their monitors DPI." - MadnessASAP
- cycomanic concludes the argument recommending "we should use something non device-dependent as our reference point, e.g. make 100% = 96 dpi," - cycomanic
- Dylan16807 argues "Because certain ratios work a lot better than others, and calculating the exact DPI to get those benefits is a lot harder than estimating the scaling factor you want" - Dylan16807