Created attachment 164944 [details]
Screenshot1

Created attachment 164945 [details]
Screenshot2

At 225% scale, I can't reproduce any text artifacts in Kickoff, but I can reproduce the issue for the letters "i" and "l" in Discover's sidebar. 

Discover is using qqc2-desktop-style while Plasma is using the Plasma style; the common denominator is QtQuick Label itself, so the issue might be in there.

Created attachment 164964 [details]
In Discover

Now that I zoom in on that screenshot, I see the letter "c" in "All Applications" exhibits the issue as well.

Created attachment 165011 [details]
In NeoChat

Found some more examples in NeoChat today. Still 225% scale.

Created attachment 165015 [details]
Yikes in NeoChat

Found another in NeoChat that downright qualifies as software gore. This is at 110% scale on a 1080p screen.

In that screenshot, the top message exhibits the issue, and the bottom message doesn't. However that's only because I selected the text in the bottom message. Before I selected it, it looked like in the top message. This shows that it doesn't have to always be that way, even on this challenging scale factor and screen resolution combination.

Isn't there a subsurface alignment issue in KWin? I run the subsurface test client mentioned in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/143#note_1343171 and there is clearly a misalignment. I run the same test client in Mutter with fractional scaling and it looked fine. It seems that it was corrected in Mutter in https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726.

Created attachment 165120 [details]
aligned-scale-test-100%

Created attachment 165121 [details]
aligned-scale-test-125%

Created attachment 165122 [details]
aligned-scale-test-150%

Created attachment 165123 [details]
aligned-scale-test-175%

>Isn't there a subsurface alignment issue in KWin?

Even if there was, the examples above aren't used subsurfaces

I experience the same issue on 6.0.1, with deformed and misplaced letters around most of the Plasma UI and System Settings, at 150% scaling. Looks like there are no issues in Widgets apps, GTK apps and Firefox. Most icons are also either blurry or pixelated, and even some UI elements. Some icons "unblur" for a short period of time when hovering over them with the cursor.

*** Bug 482720 has been marked as a duplicate of this bug. ***

Created attachment 166602 [details]
1920x1080 125% (System settings dialog)

Created attachment 166603 [details]
1920x1080 125% (System settings dialog 2)

(In reply to Marco Martin from comment #15)
> *** Bug 482720 has been marked as a duplicate of this bug. ***

Bug 482722 may also be related to this issue but the artifacts described there achieved through certain actions.

*** Bug 482633 has been marked as a duplicate of this bug. ***

*** Bug 482746 has been marked as a duplicate of this bug. ***

*** Bug 482928 has been marked as a duplicate of this bug. ***

*** Bug 481233 has been marked as a duplicate of this bug. ***

Apparently setting QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor in the environment works around this.

(In reply to Nate Graham from comment #23)
> Apparently setting QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor in the
> environment works around this.

Indeed, that makes it look WAY better.

*** Bug 483112 has been marked as a duplicate of this bug. ***

Qt 6 apparently sets the "QT_SCALE_FACTOR_ROUNDING_POLICY" environment variable to "PassThrough" by default, according to:

https://doc.qt.io/qt-6/highdpi.html#environment-variable-reference

And manually changing the "QT_SCALE_FACTOR_ROUNDING_POLICY" environment variable to "RoundPreferFloor" indeed seems to fix the issue:

https://doc.qt.io/qt-6/qt.html#HighDpiScaleFactorRoundingPolicy-enum

Can "RoundPreferFloor" be made the new default for KDE Plasma and/or can a setting for it be added to the KDE Plasma GUI system settings?

PS:

Actually any value, other than the Qt 6 default value "PassThrough", seems to fix the issue:

https://doc.qt.io/qt-6/qt.html#HighDpiScaleFactorRoundingPolicy-enum

Because the "Round", "Ceil" and "Floor" settings also seem to solve the issue (not just the "RoundPreferFloor" setting).

According to the documentation, "Round" was the default setting for Qt 5 and "PassThrough" is the default setting for Qt 6:

https://doc.qt.io/qt-6/highdpi.html#environment-variable-reference

And only the "PassThrough" setting seems to cause the issue.

The documentation also seems to suggest that using any of the non-default settings ("Round", "Ceil", "Floor", "RoundPreferFloor") would round fractional values either up or down to the next integer value:

https://doc.qt.io/qt-6/qguiapplication.html#setHighDpiScaleFactorRoundingPolicy

But the size of the items on the screen do not seem to change at first glance. The only effect that those non-default settings seem to have is that the font rendering issue is fixed when using them.

For me, I get this issue under 150% scaling and not under 125% scaling (neither i get https://bugs.kde.org/show_bug.cgi?id=459373 under 125%)

Operating System: Arch Linux 
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.8.1-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics
Memory: 30.5 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: Framework
Product Name: Laptop 13 (AMD Ryzen 7040Series)
System Version: A7

I made a post a few days back regarding this bug (https://discuss.kde.org/t/kde-6-upgrade-broke-fonts-in-wayland/13254) and am delighted to report that setting the "QT_SCALE_FACTOR_ROUNDING_POLICY" environment variable to "RoundPreferFloor" indeed seems to fix all issues I had.

Hopefully this can be resolved in a release soon, as it seems (to me at least) to be a straightforward fix. I've got no idea what implications setting this variable might have on niche situations elsewhere in KDE, but so far all good on my end. Thanks Nate for the solution!

My setup:
Thinkpad T480s
Arch linux
KDE 6.0.3
Wayland session (ofc)

*** Bug 485647 has been marked as a duplicate of this bug. ***

Created attachment 168973 [details]
1440p@125% - Normal Settings Window

Created attachment 169453 [details]
Kmail horrible font @ 125% 3440x1440

My contribution. Hope this is resolved soon.

*** Bug 487899 has been marked as a duplicate of this bug. ***

*** Bug 488623 has been marked as a duplicate of this bug. ***

Created attachment 170663 [details]
Screenshot of Konsole toolbar on X11, 150% fractional scaling, Qt rounding policy set

I can confirm that setting QT_SCALE_FACTOR_ROUNDING_POLICY to RoundPreferFloor indeed fixes the bad glyph rendering, however it also seems to disable fractional scaling on X11 for all graphical elements (fonts seem to still be properly scaled though ?), for instances icons are either scaled to 2x or to 1x depending on the ratio.

In the attached screenshot, the icons are too small compared to the text with 150% scaling factor. With scaling factors <=150%, it also makes plasma panels to be sized at 1x (but with text scaled at 150% !).

This is a Qt issue. Multiple patches have gone in recently that make this better:
- https://github.com/qt/qtbase/commit/e7ddd490cf44ecd1c59b3798294ed2812fc5a940 (in 6.7.1)
- https://github.com/qt/qtbase/commit/a5953d20e27ab73774058dd06ac514f9310a41e8 (in 6.8.0)

...But none fully fix it. 

Of note, this specific glitch only seems to affect QML labels using Text.NativeRendering. Switching to Text.QtRendering makes the issue go away — at the cost of introducing two new ones: blurrier text and excessive boldness at the topr or bottoms of all characters on a single line.

Work and investigation are ongoing.

Minimum reproducible case for me:

import QtQuick

ListView {
    width: 200
    height: 400

    model: 50

    delegate: Text {
        text: "I might be misaligned"
        renderType: Text.NativeRendering
    }
}

Scroll on that while it's located on a screen with fractional scaling, and the issue will quickly show up.

*** Bug 489101 has been marked as a duplicate of this bug. ***

Created attachment 171084 [details]
System Settings - Overview (Applications) 1920x1080@125%

Idk if this is related exactly to this specific bug, but I have 125% fractional scaling set on my 1080p display and my System Monitor Applications section in Overview looks terrible.

Created attachment 171822 [details]
Screenshot: SystemSettings::Sound volume (1.25 scaling, Plasma 6.1.2 with Qt6.7.2 on F40)

*** Bug 489076 has been marked as a duplicate of this bug. ***

By Andreas G in bug #489076

> This is a bug in qtwebengine:
> https://bugreports.qt.io/browse/QTBUG-113574
> 
> You can work around it by setting the environment variable:
> QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor
> https://userbase.kde.org/Session_Environment_Variables
> 
> Or you just wait for qt 6.8 to get released and deployed. It will be fixed
> in the next version.

Can anyone confirm that this also fixes their issue here? It does so at least for me in (Comment 42).

*** Bug 486039 has been marked as a duplicate of this bug. ***

*** Bug 491258 has been marked as a duplicate of this bug. ***

Created attachment 172622 [details]
bad text alignment on plasma 6.1.3 wayland (4K 150%)

I believe I am also experiencing this issue.

(In reply to postix from comment #44)
> By Andreas G in bug #489076
> 
> > This is a bug in qtwebengine:
> > https://bugreports.qt.io/browse/QTBUG-113574
> > 
> > You can work around it by setting the environment variable:
> > QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor
> > https://userbase.kde.org/Session_Environment_Variables
> > 
> > Or you just wait for qt 6.8 to get released and deployed. It will be fixed
> > in the next version.
> 
> Can anyone confirm that this also fixes their issue here? It does so at
> least for me in (Comment 42).

using the environment variable works around the issue I posted in the previous comment (plasma 6.1.3 QT 6.7.2 KDE Neon 24.04)

(In reply to Michel Le Bihan from comment #8)
> Isn't there a subsurface alignment issue in KWin? I run the subsurface test
> client mentioned in
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/
> 143#note_1343171 and there is clearly a misalignment. I run the same test
> client in Mutter with fractional scaling and it looked fine. It seems that
> it was corrected in Mutter in
> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2726.

That test shows there is subsurface alignment issues. Can you open another bug report for that as its unrelated to this one? I have run the tests myself and confirmed your results.

(In reply to dofficialgman from comment #49)
> That test shows there is subsurface alignment issues. Can you open another
> bug report for that as its unrelated to this one? I have run the tests
> myself and confirmed your results.

I went ahead and opened a bug for this issue.

*** Bug 489845 has been marked as a duplicate of this bug. ***

Created attachment 174652 [details]
Minimal reproducing case with Qt 6.8.0

I've got some bad news. This issue is still present in with Qt 6.8.0, and can still be easily reproduced with the minimal reproducing case in https://bugs.kde.org/show_bug.cgi?id=479891#c37.

❯ qml6 --version      
Qml Runtime 6.8.0

Looks like the bug happens because this check misbehaves on Wayland: https://invent.kde.org/frameworks/qqc2-desktop-style/-/blob/master/kirigami-plasmadesktop-integration/plasmadesktoptheme.cpp#L53-59

On X11, QScreen properly reports fractional scale factors while on Wayland they report only integer scale factors so qGuiApp->devicePixelRatio() reports the integer one, too. And the fractional one could be retrieved only from QWindow.

Also, the link in the code seem to be quite outdated, the bug is still here but tracked by https://bugreports.qt.io/browse/QTBUG-122830 now.

Similar code also present in https://invent.kde.org/plasma/qqc2-breeze-style/-/blob/master/kirigami-plasmadesktop-integration/plasmadesktoptheme.cpp?ref_type=heads#L59-91

Wanna submit a patch?

I submitted it already, as a part of a different work, to qtwayland. Sadly, David Edmundson rejected the idea.

https://codereview.qt-project.org/c/qt/qtwayland/+/590173 (most discussion including -1 is in the qtbase patch, click on the topic link)

It seems David himself also had a similar patch but abandoned it, too.

https://codereview.qt-project.org/c/qt/qtwayland/+/563344

>It seems David himself also had a similar patch but abandoned it, too.

At least I'm consistent.

I even tried pushing it upstream too. What put me off was the chromium developers showing me their version and the need for different rounding in each desktop. 

Experience so far seems to suggest re-scaling from 200 pixels to 150 pixels is always ok. Not great, not terrible.
Re-scaling from 151 pixels to 150 pixels can look absolutely trash. So if we're going to do it, we need the value spot on.

Those patches provide the right values to the user-facing APIs such as qApp->devicePixelRatio() so the code like the one in qqc2-desjtoo-styke works correctly, they don't add any rescaling.

I also wonder whether int(devicePixelRatio) == devicePixelRatio check has to be exactly that? The next integer scaling factor is 2x and I'm really doubt that any difference between QtRendering and NativeRendering is visible with such factor. qFuzzyCompare(qApp->devicePixelRatio(), qreal(1.0)) would make it work on Wayland and will also be a better fit for multiscreen setups (such as when the screen with highest DPR has integer DPR but there's still a screen with fractional DPR)

Nate, what do you think about changing the condition to qFuzzyCompare(qApp->devicePixelRatio(), qreal(1.0)), i.e. using Qt text rendering whenever scaling is enabled rather than only when the screen with highest scaling factor has fractional one? That would fix the issue and any difference in rendering is unlikely to be visible with 2x and higher anyway.

I don't have a technical opinion on the matter. David, what do you think?

>Nate, what do you think about changing the condition to qFuzzyCompare(qApp->devicePixelRatio(), qreal(1.0))

Totally makes sense. Negative part is it's not dynamic. I made a MR for an even more aggressive version and just always enable it. We'll see how that goes then if that gets pushback we can do that version.

Hey folks,

This bug has been opened since January, and there is a known workaround (setting QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor).

I hope I don't offend anyone and I don't intend to hurt or blame anyone, but I really wonder is there a good reason not to apply it at plasma level rather than asking users to set it? I understand that it's free software and developers are working on it in their spare time, but if there is not enough resources to fix the underlying issue, why not to apply a workaround?

The rounding policy workaround just disables fractional scaling (you get apps downscaled from the next integer scale factor). The Qt text rendering workaround doesn't disable fractional scaling at least, just changes the text rendering method...

(In reply to Ilya Fedin from comment #64)
> The rounding policy workaround just disables fractional scaling (you get
> apps downscaled from the next integer scale factor). The Qt text rendering
> workaround doesn't disable fractional scaling at least, just changes the
> text rendering method...

As an user I don't really care if it's downscaled from the next integer scale factor or not, I care if it's crisp or not. What I'm asking is why we don't have plasma-level workaround while we don't have a proper fix.

Hi,

Unfortunately, it's not a valid workaround, neither on X11 nor Wayland (and this bug is equally reproducible on both environments with the reproducer in https://bugs.kde.org/show_bug.cgi?id=479891#c37 as long as fractional scaling is enabled):

- On X11, it screws up the relative scaling of images and text, as I explained in https://bugs.kde.org/show_bug.cgi?id=479891#c35 for instance

- On Wayland, it completely disables native fractional rendering, instead relying on the compositor, as explained here https://bugreports.qt.io/browse/QTBUG-113574. As a result, fonts gets blurry, which depending on personal tolerance to bad font rendering, is perceived from invisible to insufferable. In particular, it makes CJK characters really hard to read at small font sizes.

> What I'm asking is why we don't have plasma-level workaround while we don't have a proper fix.

It's already present (as I linked previously), it just doesn't work if you use Wayland.

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/429

*** Bug 494217 has been marked as a duplicate of this bug. ***

For Arch users, I've published qqc2-desktop-style alternative which always forces QtTextRendering, based on David's MR https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/429, as it completely solves this issues for me with 150% fractional scaling:

https://aur.archlinux.org/packages/qqc2-desktop-style-fractional

(In reply to gilles from comment #70)
> For Arch users, I've published qqc2-desktop-style alternative which always
> forces QtTextRendering, based on David's MR
> https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/429,
> as it completely solves this issues for me with 150% fractional scaling:
> 
> https://aur.archlinux.org/packages/qqc2-desktop-style-fractional
i've applied that patch to my nixOS system, and while it does solve text rendering mostly, I still have text and icons moving around a bit when highlighting stuff on Dolphin/Dolphin as file picker, and sometimes I get leftover thin horizontal lines on Konsole.

(In reply to Luis from comment #71)
> (In reply to gilles from comment #70)
> > For Arch users, I've published qqc2-desktop-style alternative which always
> > forces QtTextRendering, based on David's MR
> > https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/429,
> > as it completely solves this issues for me with 150% fractional scaling:
> > 
> > https://aur.archlinux.org/packages/qqc2-desktop-style-fractional
> i've applied that patch to my nixOS system, and while it does solve text
> rendering mostly, I still have text and icons moving around a bit when
> highlighting stuff on Dolphin/Dolphin as file picker, and sometimes I get
> leftover thin horizontal lines on Konsole.

Actually, it's just on the Dolphin file picker. Normal Dolphin is fine.

(In reply to Luis from comment #72)
> (In reply to Luis from comment #71)
> > (In reply to gilles from comment #70)
> > > For Arch users, I've published qqc2-desktop-style alternative which always
> > > forces QtTextRendering, based on David's MR
> > > https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/429,
> > > as it completely solves this issues for me with 150% fractional scaling:
> > > 
> > > https://aur.archlinux.org/packages/qqc2-desktop-style-fractional
> > i've applied that patch to my nixOS system, and while it does solve text
> > rendering mostly, I still have text and icons moving around a bit when
> > highlighting stuff on Dolphin/Dolphin as file picker, and sometimes I get
> > leftover thin horizontal lines on Konsole.
> 
> Actually, it's just on the Dolphin file picker. Normal Dolphin is fine.

Happens on System Settings still...

> Actually, it's just on the Dolphin file picker. Normal Dolphin is fine.

If you mean file dialog, it has nothing to do with dolphin. It's a part of plasma-integration or xdg-desktop-portal-kde (yes, there are two of them).

> Happens on System Settings still...

Perhaps you didn't really applied it? That likely not as trivial as on other distros on NixOS.

(In reply to Ilya Fedin from comment #75)
> > Happens on System Settings still...
> 
> Perhaps you didn't really applied it? That likely not as trivial as on other
> distros on NixOS.

I used the following overlay
```
kdePackages = super.kdePackages // {
				qqc2-desktop-style = super.kdePackages.qqc2-desktop-style.override (old: {
					mkKdeDerivation = args: super.kdePackages.mkKdeDerivation ( args // {
						patches = [
						# ./patches/force_qttextrendering.patch
						./patches/force_nativetextrendering.patch
						];
					});
				});
			};
```

force_qttextrendering.patch being gilles' patch from the AUR, and force_nativetextrendering.patch being this https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/429/diffs#2a3d10f43f861a11d8c4e155373c59e7f24179c1_61_59.

I do think it did work, because the package did compile, before it compiled properly, it complained about the file being missing, which then I corrected, and it did recompile when I changed patches, so I assume it did work.

(In reply to Ilya Fedin from comment #74)
> > Actually, it's just on the Dolphin file picker. Normal Dolphin is fine.
> 
> If you mean file dialog, it has nothing to do with dolphin. It's a part of
> plasma-integration or xdg-desktop-portal-kde (yes, there are two of them).

Huh. I need to find which is which then, I need to ask for a feature to be added to it.

I applied the patch to the appropriate package on Solus and I haven't really noticed any of the previous glyph rendering issues. I looked through systemsettings and while I'm not really sure which KCMs are QML-based and which aren't I didn't notice any rendering issues. So my guess is that the patch is incorrectly applied (but if not please provide which KCM is having issues and I'll try to reproduce it).

(In reply to Reilly Brogan from comment #78)
> I applied the patch to the appropriate package on Solus and I haven't really
> noticed any of the previous glyph rendering issues. I looked through
> systemsettings and while I'm not really sure which KCMs are QML-based and
> which aren't I didn't notice any rendering issues. So my guess is that the
> patch is incorrectly applied (but if not please provide which KCM is having
> issues and I'll try to reproduce it).

I just scrolled up and down systemsettings multiple times and got the issues :/, this is awkward, then.

> I used the following overlay

Shouldn't it be like that?
```
kdePackages = super.kdePackages // {
				qqc2-desktop-style = super.kdePackages.qqc2-desktop-style.overrideAttrs (old: {
					patches = [
						./patches/force_qttextrendering.patch
					];
				});
			};
```
Also, I noticed you had force_nativetextrendering instead of force_qttextrendering? While native text rendering is exactly the broken?

Created attachment 175833 [details]
overlay applied, text still messy

(In reply to Ilya Fedin from comment #80)
> > I used the following overlay
> 
> Shouldn't it be like that?
> ```
> kdePackages = super.kdePackages // {
> 				qqc2-desktop-style = super.kdePackages.qqc2-desktop-style.overrideAttrs
> (old: {
> 					patches = [
> 						./patches/force_qttextrendering.patch
> 					];
> 				});
> 			};
> ```
> Also, I noticed you had force_nativetextrendering instead of
> force_qttextrendering? While native text rendering is exactly the broken?

your overlay works just like mine, no recompile, and I still have the messy text :/. I'm on 125% scale, 1920x1200 screen.

(In reply to Luis from comment #82)
> (In reply to Ilya Fedin from comment #80)
> > > I used the following overlay
> > 
> > Shouldn't it be like that?
> > ```
> > kdePackages = super.kdePackages // {
> > 				qqc2-desktop-style = super.kdePackages.qqc2-desktop-style.overrideAttrs
> > (old: {
> > 					patches = [
> > 						./patches/force_qttextrendering.patch
> > 					];
> > 				});
> > 			};
> > ```
> > Also, I noticed you had force_nativetextrendering instead of
> > force_qttextrendering? While native text rendering is exactly the broken?
> 
> your overlay works just like mine, no recompile, and I still have the messy
> text :/. I'm on 125% scale, 1920x1200 screen.

and naming aside, i made a mistake writing the other patch, indeed it did nothing, was supposed to have your changes on the 429 MR.

Yeah, most likely the qqc2-desktop-style dependency gets specified in a way that doesn't involves accessing the attribute so overay doesn't work. I.e. it's likely you have to specify the overridden package to every package using it. system.replaceDependencies.replacements is likely the easiest way to get the patched version actually used by everything.