I run a middling-width monospace font, and I can't quite fit two 80-column windows side by side at 2x without reducing the font size, but if you want that then you want smaller text anyway. (If you run a narrow font it shouldn't be an issue.) Other UI elements are not unreasonably large in my opinion, but YMMV.
That aside, I've been playing around with fractional scaling in Wayland on everything from a 6" Pinephone to 32"@4k in various configurations and it's been mostly painless. Mostly terminal, web browsing, Steam games (latter not on the Pinephone obv). I wouldn't be surprised if there can be issues with xwayland that I'm yet to experience.
Even with Intel graphics? I have stumbled on a number of showstopping bugs and moved back to X, which is also pretty horrible...
Great stability. Close to the edge of progress. And they focus on delivering real unique value on top of what others have created as opposed to reskinning and hacking Gnome.
I’ve never used Fedora but I’m keen on moving over my personal desktop the next time I have a couple of days to mess around with it.
The reason you typically see 1080p or 4k on ultrabooks is because 1080p is how you get the low entry price, and 4k is what sounds better on marketing and looks the best for text-related things (4k is not at all useless - the sharpness it provides to text is noticeable). The balance that QHD provides isn't very desirable in that market usually, although there are exceptions like the Framework laptop or the Surface Laptop 4. Usually those exceptions then also come with more unique aspect ratio displays like 3:2, though, so they aren't exactly 1440p/QHD. But they are in that density.
Resolution is independent of size. Just because it doesn't work perfectly on Linux high DPI is much nicer and easier to read.
The decapsulate on of resolution and size is btw already quite old. Games have this as well were they dynamically change the internal resolution but not the screen resolution.
And you might not care about it but: - text is much smoother - images from DSLR have higher resolution than 4k for ages and you can see the difference
The only arguments against 4k on smaller screens should be power consumption and not scaling issues. But for this we should focus on dynamic refrehsrates and similar power saving mechanism and again NOT complaining about 4k.
MacOS is doing this flawless for years. Windows can do it and under Linux it starts to be usable based on comments of this article.
https://apple.stackexchange.com/questions/193723/scaling-all...
If somebody understands the situation better on MacOS I'd be interested, but based on my experience, Windows is the only OS that gets this as close as possible to right. It's a single setting that affects all applications and I can set monitors independently and it will scale on the fly (even if it does look a little weird as you drag an app across and it dynamically shifts)
Every now and then I'll come across a app that doesn't quite deal with high DPI scaling correctly, but it is the exception to the rule.
Linux also works pretty well, but as with everything Linux, it's almost always "it depends and well, not quite" (not usually multi-monitor aware, lots of per app settings)
It renders a high-resolution image to a buffer, and then scales that when rendering to the actual screen buffer. The buffer image is at least as large as the actual screen buffer.
You can see for yourself that it isn't changing the hardware resolution of external monitors when scaling by taking a look at the actual resolution on your monitors OSD if it has done. It'll always be the native resolution.
If I tried all the possible scalings for my external monitor, the grey line around each window, to give a specific example of, is always a crisp physical one-pixel wide.
macOS creates a buffer to render to that is the same size as the physical output you're choosing to use, and is able to render with pixel precision in that buffer.
However, it is unclear to me what are the scaling ratios relative to the native resolution in your examples. In this article for Sierra you seem to be only able to pick integer factors: https://www.eizoglobal.com/support/compatibility/dpi_scaling...
Maybe? But that's ancient history.
I don't know what the ratios are - the UI doesn't expose them.
But this is all a bit arbitrary - I think the macOS API deals with an abstract 'points' unit.
Non-integer scaling (of a pixel source, vectors are different but not relevant here) either requires blending or crisp unequal-sizing artifacts.
First of all, DPI is not the metric we're interested in. That is a unit for print quality, and it has no relevance for an OS, for Photoshop, or anything we do on a screen. The operating system does not know how big your screen is. Inches nor dots are relevant; only pixels are. It would be more accurate to talk about the ratio of monitor pixels to apparent pixels. I guess Microsoft finally got the memo in Windows 11 (or was it 10?) and changed to percentages.
In MacOS, a 4K monitor set to 1920x1080 will still be 3840x2160, but it displays 4 pixels for every 1 apparent pixel. Everything scales correctly, except for legacy applications. The UI elements, text, etc. appear to be a sharper version of 1080p. In Windows land, this is the same thing as "200%." As far as I can tell, Windows does the same thing but uses scaling percentages instead of apparent resolution.
To go deeper into nitpicking, DPI is not even that misleading, if you take "inch" in DPI to be equal to 72 points as used in font sizes. Then a 72pt font on the screen with DPI X will be rendered with height of X pixels.
And yes, the OS does in fact know how big your screen is: https://en.wikipedia.org/wiki/Extended_Display_Identificatio...
I'm not sure what you mean. My MacOS does the scaling and it looks good.
How is MacOS scaling different?
There is a reason macbooks, still the gold standard for hi dpi rendering, have never had 4k panels.
Speak for yourself. The 4k display in my XPS is my favorite output device I have ever owned. I wish my rMBP had that kind of pixel density.
There have been plenty of counter examples.
Anyway, my smartphone has 1000x2000 resolution on a 6" display. The text looks perfect.
They can make very high resolution displays with very efficient energy consumption.
Feel free not to need it but my DSLR and my smartphone both take 4k and higher resolution pictures for years.
Yes I want such a display on my 14" laptop.
I do like the MacBook pro screen and it's much better than 1080p. True.
Because that's really low.
My 14 inch laptop is 1964 rows and I wouldn't really want anything lower than that.
But a 1080p screen would be a no for me. At 2256x1504 on 13.5" screen I think Framework laptop would probably be fine at 100% ie no scaling
To get nice integer scaling one could render at 15360x8640 (16k) which is 5x3072x1728 and 4x3840x2160 but I doubt that's what Wayland is doing. No common graphics card could handle that.
The font hinting relies on the resolution too. By scaling the rendered pixmap 125% the fonts would look bad too. Rendering the fonts in a larger size at the native screen resolution should look better.
https://discourse.gnome.org/t/how-fractional-scaling-works-i...
For scaling 125%, the client windows are rendered at 2x their size and sampled down. On the parent's system, a full-screen window would be rendered at 6144x3456 and scaled down to 3840x2160 (0.625%).
This gives a blurry result and is taxing on the graphics chip.
Qt apps and Firefox support scaling themselves which gives a much crisper result for fonts and line-art.
I've basically resigned myself to running Sway in 1.5x scale mode, which means that things get rendered at 2x and scaled down. Sway does about as well as I think any desktop environment could be expected to, but it's never going to be the same as rendering at true screen resolution. Alas, running in 1x or 2x and using font settings to handle it breaks down the moment you connect to an external display that really is 1x or 2x.
That said, I love the rest of the laptop (well, maybe except the battery life), so my hope is that at some point we can buy a replacement screen at a more useful resolution, at which point I'll be first in line to buy and install it.
I'm doing this, in particular on a 24" 4k screen. It's true that it may look a bit "weird", in that fonts are huge compared to other UI elements.
However, for me that's a win. I don't care to have huge buttons or what have you, I mostly use shortcuts. So I get nice, sharp fonts and also get to have smaller UI elements which leave more screen space for the text.
* Gnome the desktop -> org.gnome.mutter/experimental-features "scale-monitor-framebuffer". Only integer scales available without this. Following assume that this is enabled.
* gnome apps: work great out of the box
* QT apps: Qt5 requires QT_QPA_PLATFORM=wayland environment variable to force wayland backend. Enabled by default in Qt6. Used to be quite bad ~1-2 years ago, but is now usable.
* Firefox: MOZ_ENABLE_WAYLAND=1
* chromium and electron: --ozone-platform=wayland seems fine for chrome, but some electron apps went crazy when moving between windows with different scale. Maybe the electron app bundled an older chrome version. No issues (except less sharp text) when not enabling the experimental wayland backend.
Now we still would need to scale images etc, but that is much less an issue than fractional scaling text or lines etc.
(I just went to check my several-years-old impressions against Darktable’s almost-undocumented config file, and... it no longer seems to have these settings? I’m not sure.)
Unfortunately, the “UI scale” thing seems to be baked into Wayland nowadays; I have no idea how to get Evince to realize that an A4 sheet at 100% should be 210 cm wide whatever my screen resolution and “UI scale”.
Modern CSS is quite close to Turing complete, so an entirely constraint-driven design (which is what's needed when more than one unit is being chosen by the user) ought to be feasible. You need at least "real world units" for stuff like the minimum size of touch targets, and "angular units" (like CSS pixels) for the general scaling of widgets. Plus it would be nice to add a separate scaling factor for text, since users differ widely in what they find most readable. So that makes for three independent settings, in the general case.
That touch targets need absolute lengths is a good point.
> So that makes for three independent settings, in the general case.
Yes, and you’ll notice that’s what Darktable does (or did) :) I’m not unsympathetic, just have never seen it done in a moderately complex situation.
> Modern CSS is quite close to Turing complete, so an entirely constraint-driven design (which is what's needed when more than one unit is being chosen by the user) ought to be feasible.
I suspect it’s not a question of theoretical expressive power so much as ergonomics: allowing easy description of (what people think about as) simple things. It probably doesn’t have to be precisely; if a full constraint-based / linear programming approach[1] is the way to go, I expect designers will adapt, it’s just that last I checked those could be quite tricky to use: small changes could lead to drastic rearrangements of the layout, and as soon as you try to add a couple of breakpoints the whole thing becomes NP-complete.
It’s like, say, LR(k) parsers. LR(k) parsers are nice, fast, and good at expressing our intuitions about ambiguity (unlike ordered choice). They are expressive enough for almost anything you might want to say. But nobody really wants to work with them, the failures are tricky and hard to predict, and they lack many things you want for modularity (say, closure under unions).
It seems to me that the situation with truly resolution-independent layouts is similar in this respect: we can technically do them, to some extent, but they are a pain, so nobody does. And it’s not so much a problem of finding the perfect language as a problem of figuring out what it is that we want to say that seems so simple in our heads.
Sure, that's a given with the constraint satisfaction approach but NP-complete problems work just fine when N is small enough.
Android is still about the only OS with reliable density independence. It's also the only one where things like DPI were an initial part of the UI system, and not something bolted on later.
Windows has been trying to retrofit density independence for nearly a decade now, and it's still pretty hit or miss. Apple didn't bother trying at all, and has been more successful at pretending it works (so scale rendering by whole numbers only, then fractionally scale the resulting image to the actual display size). Web browsers mostly went the Apple route, but we all also regularly expect pinch/zoom scaling to fix any glaring issues anyway and just accept it's kinda janky. Linux... well, Linux is still struggling with the basics of putting stuff on screen (Wayland vs. X11). I wouldn't hold my breath for that ecosystem to get this UX refinement working well anytime soon. Especially not across the many UI widget systems, window managers with differing border decorations, DEs, etc...
The problem, as usual, is getting the apps to actually use it.
(This doesn't handle multi-monitor setups well, since font size would be the same for them all. But multiple monitors were not exactly common back then.)
WM_DPICHANGED is a late addition, yes, but it's only necessary for the apps to dynamically reflow if the user changes that setting. Before it showed up, you'd have to restart the app for it to register the new value - but that does not preclude DPI independence as such.
The real problem was that almost everything in Win32 outside of CreateDialog uses device pixels to position. You were supposed to use GetDialogBaseUnits and/or MapDialogRect manually to get the correct values, and very few apps did.
For another early example, Visual Basic (VB6, pre-.NET, so we're talking 1998) measured everything in twips.
Not entirely. The font size can still be changed independently of the DPI, and not everything should be scaled as a result. Things like dividing lines and padding probably shouldn't be scaled when the font size is increased.
You still need a distinct DIP value independent of scaled font size. So the value of 'dp' vs. 'sp' in Android terms, which it looks like Windows' now also has that distinction.
And yeah this is ignoring that things like the visual winforms tool in Visual Studio really just wanted to operate in fixed positions, and just getting things to work when the window was resized wasn't always intuitive or obvious. So even if the APIs were there, the ecosystem definitely didn't care about it and Microsoft's own tools definitely didn't help.
Fixed layouts is orthogonal to all that - so long as those fixed layouts are defined in DPI-independent units, they will scale just fine. FWIW in WinForms (and also Delphi VCL, where this originated) you'd normally use anchors to design layouts that scale when the window is resized. Granted, it's nowhere near as flexible as proper layout containers - which WinForms (2.0+) also has, and which the visual form designer also supports, although it can be a pain to work with them.
I've still had some issues with some applications not scaling their widgets properly, but it's mostly ok.
I’m on PopOS running Wayland with fractional scaling to 200%. It looks fantastic imo and have only had some issues with Guake terminal when plugged in to an external monitor, which I believe may be a Guake-Wayland-specific bug.
I tend to prefer 1080p for this reason on 12-14" screens. My Thinkpad X13 gen 2 has a 13.3", 1920x1200 screen, windows sets it to 150%, which seems ok, although Ubuntu works well for me without scaling still. The Frame work laptop has an even higher res (2256x1504). I do hear people scaling the fonts and that seems to be a nice solution... I remember from back in the old days that I never really liked the look of this.
What do people think of this? I'm hoping that in the future you can choose the screen (and easily get replacements as well, I hear they are working on that).
Edit: I hope these issues are being addressed by established DE's, I'm assuming they won't be an issue on Canonical's (hypothetical ;)) Flutter based DE that's (obviously ;)) coming and on System76's Rust based new DE for Pop OS [0].
[0]: https://www.theregister.com/2021/11/08/system76_developing_n...