15.6″ 1366×768: 100ppi. It could be improved by 90% scaling, but that doesn’t tend to work quite so well. Basically everyone uses it at 1×.
15.6″ 1920×1080 (1080p): 141ppi. Generally comfortable at 1–1.25×, most will use at 1×.
15.6″ 2560×1440 (1440p): 188ppi. Generally comfortable at 1.33–1.75×, most will use at 1.5×. Definitely uncomfortable at both 1× and 2×. If you don’t like fractional scaling, you don’t want 1440p.
15.6″ 3840×2160 (4K): 282ppi. Generally comfortable at 2–2.5×, most will use at 2×.
These figures I’m suggesting are aiming for about 110–140dpi. I have a 15.6″ 2560×1440 screen, and 1.5× scaling mostly works very well, basically perfectly under Windows which I never use and with only minor issues under Linux/Sway with high-DPI XWayland patches once I’ve manually intervened to fix a few variously broken things.
Hmm, I guess I didn't think about the 15.6 inch size in laptops. I have a 14 inch laptop so I was thinking in terms of that size. 1080p on my laptop needs 1.2 — 1.3 scaling to look "normal". I know people dismiss this as personal taste but 1) IINM, Windows defaults to 125% automatically on such a display and 2) I have a hard time reading text without scaling my 14 inch 1080p display.
Sure, people, resort to scaling just the fonts but everything looks out of place if you do that. The fonts are big but the UI elements are still small.
Personally, I chose to compromise as well by scaling just the fonts on SwayWM because fractional scaling introduces slightly noticeable degradation of font quality which is unacceptable to me.
But yeah, in that case, 4K display on a laptop looks like a safe bet so I would only go for that in the future. Thanks.
14″ is an uncomfortable size for integral scaling: past 1366×768 (112ppi), all of the popular sizes call for fractional scaling: in my rough guide of 110–140ppi, that’s about 110–140% for 1080p (so the 125% you cited is good), about 150–190% for 1440p, and about 225–285% for 4K.
(13.3″ works better: 100% for 1366×768, 120–150% for 1080p so no integer there, 160–200% for 1440p, 240–300% for 4K.)
Fractional scaling in Sway doesn’t degrade quality in any way in Wayland windows: it leaves the scaling to the app to execute, and I haven’t come across a single app getting it wrong. Text will be rendered perfectly. Pixel-precise stuff can be a tad funny, e.g. a 1px border on an element in Firefox will be rendered as one or two device pixels in most contexts.
But then there’s anything still using X11: without the high-DPI patches, XWayland renders at 1× and scales it up so that it’ll look bad for any scale higher than one, whether fractional or integral. With the patches, you get to decide what to do.
On my 1440p 15.6″ display, I have scale 1.5 and xwayland scale 3, which normally works very well, but I do have to drop it to 1 occasionally for some things due to apps that don’t do scaling and the fact that the patches are still imperfect and you can actually soft-lock apps when they try to open certain windows (mostly popups, including menus) until you drop the scale.
> Fractional scaling in Sway doesn’t degrade quality in any way in Wayland windows: it leaves the scaling to the app to execute, and I haven’t come across a single app getting it wrong.
Funny you say that considering Firefox goes haywire if you use it on Sway with fractional scaling.
Other Qt apps like Qterminal are also not able to show tooltips normally if you enable scaling. Some Qt apps which I absolutely adore like Spectacle and Gwenview don't work at all though this might be a different issue.
> But then there’s anything still using X11: without the high-DPI patches, XWayland renders at 1× and scales it up so that it’ll look bad for any scale higher than one, whether fractional or integral. With the patches, you get to decide what to do.
The unofficial XWayland HiDPI patches? Yeah, I'm not gonna use them if they're official. It's a pain to compile and build complex packages like these. The AUR is fine for small and casual packages with a few dependencies but nothing complex, I feel.
Those issues are all for any scaling, not just fractional—the narrative was just muddied because it was first reported by users of fractional scaling. gtk!3898 fixes #6426, and probably the other two too because they seem to all be manifestations of the one root cause. (Incidentally, remember Firefox uses X11 unless you manually turn on its experimental Wayland support via MOZ_ENABLE_WAYLAND=1.)
Tooltips are working in all the Wayland Qt apps that I have (marble-qt, zeal-git, musescore, telegram-desktop).
If you have an AUR helper, replacing {sway,wlroots,xorg-xwayland} with {sway,wlroots,xorg-xwayland}-hidpi-git is really easy and not at all slow, though at least sway and wlroots do interdepend so that if you upgrade one you should rebuild the other or things may break (happened to me a couple of months back, there was a .so version bump). I decided that I’d rather have not-quite-perfect scaling and any package management concerns, rather than having XWayland content always look terrible. And remember that’s true of any scaling factor other than one.
> gtk!3898 fixes #6426, and probably the other two too because they seem to all be manifestations of the one root cause.
I hope the fix lands on my desktop soon because I'm still facing those issues if I enable scaling. Even when I don't enable scaling and just use the Zoom option in Firefox, it starts behaving strangely for dropdown menus in Firefox settings. The menus aren't where they should be and sometimes flicker.
> (Incidentally, remember Firefox uses X11 unless you manually turn on its experimental Wayland support via MOZ_ENABLE_WAYLAND=1)
Yeah, I've exported this as a user environment variable and confirmed with xeyes that Firefox runs natively in Wayland.
> Tooltips are working in all the Wayland Qt apps that I have (marble-qt, zeal-git, musescore, telegram-desktop).
Please let me know if it works for you on Qterminal.
I'd also love to have Spectacle working on Sway. It starts natively in Wayland but fails to screenshot anything and tells me to open a bug report.
Gwenview looks broken on Sway/Wayland. The colors are all messed up.
> If you have an AUR helper, replacing {sway,wlroots,xorg-xwayland} with {sway,wlroots,xorg-xwayland}-hidpi-git is really easy and not at all slow, though at least sway and wlroots do interdepend so that if you upgrade one you should rebuild the other or things may break (happened to me a couple of months back, there was a .so version bump). I decided that I’d rather have not-quite-perfect scaling and any package management concerns, rather than having XWayland content always look terrible. And remember that’s true of any scaling factor other than one.
I'm not really using any XWayland programs at the moment except rofi so I don't think installing those packages from the AUR is worth it for me. I'd be happy to use them if they were available as official precompiled binaries.
Any ideas why these patches aren't merged to master? Some disagreements among devs?
I've got some more anecdata around this. Chrome tooltips get a bit funky with fractional scaling on wayland (using chrome's ozone wayland platform interface).
(Either that, or it's something weird with my sway/monitor configuration, but I don't have anything unusual).
15.6″ 1920×1080 (1080p): 141ppi. Generally comfortable at 1–1.25×, most will use at 1×.
15.6″ 2560×1440 (1440p): 188ppi. Generally comfortable at 1.33–1.75×, most will use at 1.5×. Definitely uncomfortable at both 1× and 2×. If you don’t like fractional scaling, you don’t want 1440p.
15.6″ 3840×2160 (4K): 282ppi. Generally comfortable at 2–2.5×, most will use at 2×.
These figures I’m suggesting are aiming for about 110–140dpi. I have a 15.6″ 2560×1440 screen, and 1.5× scaling mostly works very well, basically perfectly under Windows which I never use and with only minor issues under Linux/Sway with high-DPI XWayland patches once I’ve manually intervened to fix a few variously broken things.