Wayland exposes to applications only integer values of scale factor, that is the user set a scale to 1.75, and apps receive a scale factor of 2. Then at rendering apps renders themselves at 2x and the compositor (KWin) scales them down to 1.75, downscaling the rendering, washing off details of the application render. Fonts are most visible but images are concerned as well. This is not exclusive to KWin and it is a general current shortcoming of wayland protocols and architecture. It is reported upstream at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/47 This is a well known issue in the community: https://www.reddit.com/r/kde/comments/lficfe/wayland_fractional_scaling_may_be_sort_of_a/ https://www.reddit.com/r/kde/comments/pfvl9j/wayland_fractional_scaling_may_be_sort_of_a/ This bug is just a bug to keep track of the issue in our bug tracker as it will require kwin work to get fixed in plasma anyway. https://bugs.kde.org/show_bug.cgi?id=438401 seems related.
I wonder if there is also room to use a better downscaling algorithm here. Some produce blurrier results than others. If it's possible, IMO it would be better to use one that produces sharper output.
(In reply to Nate Graham from comment #1) > I wonder if there is also room to use a better downscaling algorithm here. > Some produce blurrier results than others. If it's possible, IMO it would be > better to use one that produces sharper output. It's worth looking into, imho, but afaik downscaling flushes sub-pixel AA down the toilet. It may not be easy to get significantly better results. Just be mindful of ROI, that's all I'm saying.
To support the proposal for fractional scaling, Qt applications need to be able to change their scaling at runtime. Scaling of applications is explained in <https://doc.qt.io/qt-5/highdpi.html> and <https://doc.qt.io/qt-6/highdpi.html>. On Windows, the setting 'Per-Monitor DPI Aware' seems close to what this proposal needs. The applications gets a buffer corresponding the the actual pixels on the screen and also a scaling factor at which the UI should be rendered. A dynamic scale factor per window would be fantastic. There could be a 'zoom resize' (shift + drag border) where the aspect ratio and layout would stay the same, but the fonts and icons got larger or smaller.
There has been an interesting protocol proposal involving major Wayland protocols designers: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/143 Please don't comment there, leave the specialists free of distraction. The path forward is not clear yet, but it is still good to keep the community somewhat in the loop.
In progress with https://invent.kde.org/plasma/kwin/-/merge_requests/2598!
A wayland protocol has landed. Kwin support has landed. It is of no effect without relevant client side code. Support for Qt6 and SDL has been added. It isn't in any clients at this point in time. We've done all we can our side, but don't expect immediate changes.
(In reply to David Edmundson from comment #6) > A wayland protocol has landed. Kwin support has landed. > It is of no effect without relevant client side code. Support for Qt6 and > SDL has been added. It isn't in any clients at this point in time. Will it be possible to have this back-ported to Qt 5 to be used with KDE/Plasma 5?
(In reply to G360 from comment #7) > (In reply to David Edmundson from comment #6) > > A wayland protocol has landed. Kwin support has landed. > > It is of no effect without relevant client side code. Support for Qt6 and > > SDL has been added. It isn't in any clients at this point in time. > > Will it be possible to have this back-ported to Qt 5 to be used with > KDE/Plasma 5? Unfortunately no, this is an important code change that requires Qt update, not just kwin changes. Given Plasma6 is a few months away, this does not make it particularly important to work further on this.