SUMMARY Qt client apps using system Qt 5.15.8 still use the old downscaling mechanism to deal with fractional scaling, instead of wp-fractional-scale-v1, leading to visual artefacts. STEPS TO REPRODUCE 1. Set "Scale" to fractional eg 135% in Display Configuration 2. Open a Qt app OBSERVED RESULT App is upscaled to 2x then downscaled. This produces aliasing artifacts as detailed previously here [1] EXPECTED RESULT Native scaling... like what is done by XWayland in "Apply scaling themselves" mode. See attached picture. On the left is XWayland (Platfom=xcb) and on the right Wayland. SOFTWARE/OS VERSIONS KDE Neon based on ubuntu 22.04.2 (available in About System) KDE Plasma Version: 5.27.1 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 libqt5core5a Version: 5.15.8+p22.04+tunstable+git20230209.0323-0 python3-pyqt5 Version: 5.15.9+dfsg-1+22.04+jammy+unstable+build21 ADDITIONAL INFORMATION I believe the previous scaling is offered by Qt since 5.6 and is described here [2] and [3]. And the new one was announced by Nate here [4]. I think the KWin part landed: ``` > wayland-info | rg frac interface: 'wp_fractional_scale_manager_v1', version: 1, name: 10 ``` but maybe the Qt patches were not added to Neon's patch collection? Is this [5] related? how can I verify if the Qt5 client libs have support? I attach the small PyQt sample [6] used to show that the scale given to the app is 2x and the screen geometry and physicalDotsPerInch is fake (dpi 115.834 instead of 163), with system Qt 5.15.8. [1]: https://www.reddit.com/r/kde/comments/lficfe/wayland_fractional_scaling_may_be_sort_of_a/ [2]: https://www.qt.io/blog/2015/01/27/qt-weekly-24-high-dpi-qtwayland [3]: https://www.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6 [4]: https://pointieststick.com/2022/12/16/this-week-in-kde-wayland-fractional-scaling-oh-and-we-also-fixed-multi-screen/ [5]: https://invent.kde.org/qt/qt/qtwayland/-/commit/23d3fc7 [6]: https://gist.github.com/eddy-geek/2a682a415abb5d351537ae3fc865dffd
Created attachment 156688 [details] Shows clear scaling with XWayland(XCB), artifacts with Wayland
Created attachment 156689 [details] image used to find aliasing issues The previous screenshot has been obtained by running code in [6] with dpitest1px.png in the folder and this command: > QT_QPA_PLATFORM=xcb /usr/bin/python3 ./qt6-dpi.py 5 for the left window, and without ...xcb for the right window to better see the difference, beware that most software (Chrome, Firefox, Eye of Gnome) apply antialiasing. Gwenview is fine... without fractional scaling ;-)
wp-fractional-scale-v1 is implemented in Qt6 only. It's most likely not going to be implemented in Qt5, because that is in strict bugfix-only mode and supporting a new wayland protocol is a bit too large and complex for that
Created attachment 156690 [details] plasma 5.27.1 - artifacts with both XWayland(XCB) and Wayland I had not rebooted after 5.27.1 final so I was probably mostly on Neon testing from 2023-02-17 So, attaching this as the current status. Unfortunately 5.27.1 changes nothing for the platform=wayland scenario -- and it seems to regress the platform=xcb XWayland scenario, making it blurry (not that I care)
(In reply to Nicolas Fella from comment #3) So, nothing can be done on this before Plasma 6 ? Am I missing something or is the only thing missing a backport of https://invent.kde.org/qt/qt/qtwayland/-/commit/23d3fc7 into branch `kde/5.15`? If I were to try to submit a PR for this, it would be rejected?
(I understand upstream won't backport it, this why I'm asking specifically about the KDE Qt patch collection or whatever the name of what goes into Neon)
> Am I missing something or is the only thing missing a backport of https://invent.kde.org/qt/qt/qtwayland/-/commit/23d3fc7 into branch `kde/5.15`? Correct > If I were to try to submit a PR for this, it would be rejected? It's not my decision to make. I'd say it's possible that it would be accepted, but not certain > So, nothing can be done on this before Plasma 6 ? Plasma 6 is only semi-relevant. What matters is what Qt version the applications use. Qt5-based applications would still be broken even in Plasma 6, and Qt6-using applications would be fine in Plasma 5
David, what do you think about this?
I've noticed similar issue on Arch Linux with latest Plasma (5.27.3). I'm using two monitor setup with 125% scaling. Out of curiosity I've backported two Qt6 patches regarding fractional scaling. The repository with backports is available at: https://github.com/dobo90/qtwayland/tree/kde/5.15_fractional_scaling. After two days of testing I've noticed following things: The bad ones: * Sometimes fonts are "pixelated" (for example when opening Monitor Settings). * Some of the icons are also "pixelated" (for example icon of QTerminal in About dialog). * LibreOffice renders way too big text (it's not usable on Qt backend). The good ones: * The are no artifacts (horizontal blinking lines) in QTerminal application (previously they were really annoying). * Fonts seem to be more readable (maybe it's only my subjective opinion). I've tested also the qt6-dpi.py application mentioned here. It reports devicePixelRatioF equal to 1.25 (instead of 2.0). I can clearly see the difference in font rendering (when comparing two screenshots - before and after enabling fractional scaling). But I don't know how should I interpret the rendered test image. This is my first comment in this bugzilla. I haven't done any Qt/KDE related work yet - I've just noticed a slight font blurriness on Plasma. If my comment is irrelevant, please ignore it. If someone wants to test my changes I would be very glad. Maybe in the future it will be possible to add wp-fractional-scale-v1 to Qt5 guarded by an environment flag (for example). I'm aware that Plasma 5 is in a maintenance state but well..
>David, what do you think about this? You'll fix 95% of cases, I did most my dev work against Qt5. The problem is there's 5% that will explode massively. Most notably systemsettings. There's a bug with QQuickWidget and fractional scaling, that we have a workaround for that uses Screen.dpi; but our screen DPI is an integer so that thing fails. (I assume that's what Dobroslaw is referring to) There's also the issue of communicating changes; Qt only looks for DPR changes when the screen changes. Get that out of sync and you're in trouble. I added new code to QtBase for that, but that's not easy to backport, there's new events. Backporting alone isn't enough. There's a lot more to do on top. I'm not sure it's worth it.
Some relevant links: https://codereview.qt-project.org/c/qt/qtbase/+/447074 https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/206
Note this was the Qt5 branch I was using: https://invent.kde.org/davidedmundson/qtwayland/-/tree/work/d_ed/fractional_scale_backport?ref_type=heads it's a year old now, so there probably are differences.
1) I've backported https://codereview.qt-project.org/c/qt/qtbase/+/447074 to https://github.com/dobo90/qtbase/tree/kde/5.15_fractional_scaling 2) I've cherry-picked https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/206 to https://github.com/dobo90/qqc2-desktop-style/tree/fractional_scaling 3) I've cherry-picked https://codereview.qt-project.org/c/qt/qtdeclarative/+/447075 to https://github.com/dobo90/qtdeclarative/tree/kde/5.15_fractional_scaling (I don't know if it's need but I've found it on Gerrit). The result is that after opening systemsettings, text on each control is pixelated. But after changing the setting page by clicking on any item, text on most of the controls is rendered properly. I will try to do some digging but my knowledge is very limited in that matter.