Better KWin Wayland HiDPI Support Still Baking

[phoronix]

Phoronix: Better KWin Wayland HiDPI Support Still Baking

KDE developer David Edmundson has shared a bit of an update regarding KDE's Wayland high DPI handling, particularly for multi-monitor setups...

http://www.phoronix.com/scan.php?page=news_item&px=KWin-Wayland-HiDPI-Misses-5.10

[gotwig]

And GNOME devs dont give a f*ck The HiDPI support in GNOME is so bad... i have a 14" FullHD screen and I can't use it, because it doesnt support floating values like 1,2 scaling, but only full integer scaling like 2x time scaling or 3x scaling. Super useless. For years.

But hey , its gnome, I guess they focus on recipe apps instead.

[rtfazeberdee]

And GNOME devs dont give a f*ck The HiDPI support in GNOME is so bad... i have a 14" FullHD screen and I can't use it, because it doesnt support floating values like 1,2 scaling, but only full integer scaling like 2x time scaling or 3x scaling. Super useless. For years.

But hey , its gnome, I guess they focus on recipe apps instead.

I'm sure Griffin-troll will have something to say about that...

[darkbasic]

"Despite Qt having quite good fractional scaling support, the wayland protocol limits itself to integers. This is in the very core protocol and somewhat hard to avoid. However, there's technically nothing stopping kwin from scaling to a different size than it tells the client to scale at..."

Why not fixing the Wayland protocol instead? Why did they choose to not allow fractional scaling?

[CrystalGamma]

I have yet to understand why Wayland uses scaling factors based on 96DPI instead of putting DPI right there in the protocol. (Maybe the compositor could have transmitted two numbers per axis: the number of pixels in a meter and the (pixel) size of the smallest desired interactive element, because you want bigger buttons on a touchscreen than a system with only a mouse …)

[starshipeleven]

Haha. KDE actually contributing to Wayland?

Please note, the same applies to GNOME here (as none has yet sent in a patch for this). Where is the businness-grade QA when you need it most?

[andrebrait]

Regarding GNOME, I have found that setting the font scaling to 1.5 using the GNOME Tweak Tools provides a very satisfying result (for me, at least) for the time being. It scales some of the UI as well.

[polarathene]

I have yet to understand why Wayland uses scaling factors based on 96DPI instead of putting DPI right there in the protocol. (Maybe the compositor could have transmitted two numbers per axis: the number of pixels in a meter and the (pixel) size of the smallest desired interactive element, because you want bigger buttons on a touchscreen than a system with only a mouse …)

I know that in the browser world CSS is based on 96DPI or rather 96 pixels per inch? IIRC, a square of 96px width/height would be 1 inch width/height even on 120dpi or 300dpi display/resolution/print. You could apply a zoom/scaling factor though(I think this is desktop browser +/- zoom buttons), depending on style rules that may get ugly vs an actual scale/zoom that you might do in your mobile browser with your hand(scaling the viewport not values).

No idea what Wayland is doing, but maybe it's more like a reference value that would translate to actual DPI of the device(see PhantomJS for printing PDFs of webpages, Linux/Windows/macOS output different sizes due to their native OS DPI(different from display DPI), not sure if that's been fixed yet, I know a fix ended up flipping the problem). Scaling by integer values might be a quality thing if it's scaling texture pixels(assuming rendered contents is on the GPU managed in textures), floating point values in that approach tend to have issues like quality. If instead the values could be scaled prior to being rendered into pixels/textures, floating point might work better then?(scaled values that are not integers may get rounded up/down to fit a full pixel however where rendered elements might look slightly offset) This is just going off my experience working with various technologies in the past(Starling framework for Adobe AIR using GPU on mobile devices and how scaling worked there, and CSS for websites printing to PDFs).

With web you'd be able to have individual elements be at a larger scale or different style based on pixels/DPI and width/height of the element/container available. On Starling, you could do similar but you could also note the scaling factor to decide if elements like buttons should be larger and treated differently.

[MoonMoon]

Wise choice, and no suprise. With a code base like KDE it is expected that your fix is another man's bug. There is no shame to being second or third. Meanwhile the reference desktop will move further ahead completely ignoring inaccuracies from gotwig

At this point I have to ask myself if I should laugh about you or feel sorry for you. You life must be really miserable if you have to define yourself over the work someone else has done instead of your own achievements.

[GreatEmerald]

Huh, fractional scaling not being part of Wayland is really odd. And quite sad for my tablet, which is 144 DPI... that's exactly 1.5x. 1x is way too small and 2x is way too large.