Bug 479891

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.

Git commit e82957f5e6fc72e446239e2ee5139b93d3ceac85 by David Edmundson.
Committed on 22/11/2024 at 21:57.
Pushed by davidedmundson into branch 'master'.

Use Qt text rendering when high DPI scaling

It is known that native rendering performs badly with scaling and an
existing workaround is in place.

The current check does not work on Wayland that has per-window rather
than per-screen scaling. Given Qt changes hinting preferences when any
scaling is used anyway, we may as well commit to using the non-native
rendering throughout.

For QtQuick the Qt renderer is more performant, handles transformations
better and avoids this issue. Given the results look basically
identical, we can simplify the existing code.

M  +9    -8    kirigami-plasmadesktop-integration/plasmadesktoptheme.cpp

https://invent.kde.org/frameworks/qqc2-desktop-style/-/commit/e82957f5e6fc72e446239e2ee5139b93d3ceac85

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

(In reply to David Edmundson from comment #85)
> Git commit e82957f5e6fc72e446239e2ee5139b93d3ceac85 by David Edmundson.
> Committed on 22/11/2024 at 21:57.
> Pushed by davidedmundson into branch 'master'.
> 
> Use Qt text rendering when high DPI scaling
> 
> It is known that native rendering performs badly with scaling and an
> existing workaround is in place.
> 
> The current check does not work on Wayland that has per-window rather
> than per-screen scaling. Given Qt changes hinting preferences when any
> scaling is used anyway, we may as well commit to using the non-native
> rendering throughout.
> 
> For QtQuick the Qt renderer is more performant, handles transformations
> better and avoids this issue. Given the results look basically
> identical, we can simplify the existing code.
> 
> M  +9    -8    kirigami-plasmadesktop-integration/plasmadesktoptheme.cpp
> 
> https://invent.kde.org/frameworks/qqc2-desktop-style/-/commit/
> e82957f5e6fc72e446239e2ee5139b93d3ceac85

Does the environment variable: QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor
Still need to be set ?

No, that should be unset now.

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

Created attachment 176164 [details]
Dolphins preview

There is there some mis-rendering in dolphins preview pane (see attachment)

That's something else. This bug report is about QML text in desktop apps. That text is rendered by the thumbnailer plugins, which isn't QML.

should I open a new report or is there already one?

New one please.

(In reply to Robby Engelmann from comment #91)
> There is there some mis-rendering in dolphins preview pane (see attachment)

This bad image scaling-related issue is different and is already well known in various KDE apps:
- Kolourpaint https://bugs.kde.org/show_bug.cgi?id=436615
- Kontact https://bugs.kde.org/show_bug.cgi?id=482128
- Kmail https://bugs.kde.org/show_bug.cgi?id=488324
- It is also visible in System Settings > Text & Fonts > Font Management

It's not accurate that "QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor" no longer needs to be set.

Setting "QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor" still fixes the issue (or at the very least makes it less severe), just like before.

Why do some state that it would no longer be necessary to set "QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor" when it still is necessary?

That's a different way to fix the bug. The thing we merged fixes it in another way that makes it no longer necessary to set that.

Please don't re-open closed bug reports.

> Why do some state that it would no longer be necessary to set "QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor" when it still is necessary?

Perhaps you have some other bug, not the one this report about? Some people were uploading screenshots of unrelated bugs here.

(In reply to Nate Graham from comment #97)
> The thing we merged fixes it in another way that
> makes it no longer necessary to set that.

It's not fixed in the latest KDE Plasma release (version 6.2.4. with Frameworks version 6.8.0).

The "Version Fixed In" field of this bug report seems to indicate that it would be fixed with Frameworks version 6.9.0, i.e. with a future release?

Will the fix be included in KDE Plasma version 6.3 then?

(In reply to NW from comment #99)
> (In reply to Nate Graham from comment #97)
> > The thing we merged fixes it in another way that
> > makes it no longer necessary to set that.
> 
> It's not fixed in the latest KDE Plasma release (version 6.2.4. with
> Frameworks version 6.8.0).
> 
> The "Version Fixed In" field of this bug report seems to indicate that it
> would be fixed with Frameworks version 6.9.0, i.e. with a future release?
> 
> Will the fix be included in KDE Plasma version 6.3 then?

KDE Plasma and KDE Frameworks are two separate things that are released independently. KDE Frameworks 6.9.0 was released today, so you'll see this "fixed" once your Linux distribution updates the packages for that.

Thanks, from the following Wiki it somewhat looked like Plasma and Frameworks releases would be tied together:

* https://community.kde.org/Schedules/Plasma_6#Dependencies

But from the following Wiki it's more clear that they are not:

* https://community.kde.org/Schedules/Frameworks

Just updated from Frameworks 6.8.0 to Frameworks 6.9.0 (and unset "QT_SCALE_FACTOR_ROUNDING_POLICY=RoundPreferFloor") and the issue is gone, thanks.

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

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

I was able to reproduce this again briefly. I installed KDE (on NixOS), and set my scaling to 125% (it was 100%), and I noticed that the text on System Settings was broken like this again. That said, it could only be reproduced once. When I closed the System Settings window and reopened it, the issue wasn't present, and changing scaling values didn't make it reappear.

Created attachment 178787 [details]
System Settings screenshot showing the bug

Created attachment 178788 [details]
Icons-only task manager widget settings

When scrolling on this widget's settings, I noticed that the text jumps around, and, in some "stops", the text can end up distorted

Created attachment 178789 [details]
Total CPU Use widget settings

Glitched text, appears when scrolling to the bottom of the list

Are you sure you have KDE Frameworks with the fix?

(In reply to Ilya Fedin from comment #109)
> Are you sure you have KDE Frameworks with the fix?

qqc2-desktop-style is version 6.11, and

Operating System: NixOS 25.05
KDE Plasma Version: 6.3.1
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
Kernel Version: 6.13.3 (64-bit)
Graphics Platform: Wayland
Processors: 16 × 12th Gen Intel® Core™ i5-12500H
Memory: 23.2 GiB of RAM
Graphics Processor: Intel® Iris® Xe Graphics
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: Vivobook_ASUSLaptop X1605ZA_X1605ZA
System Version: 1.0

hmmm. I have a personal patch that disables stem darkening on qt5/qt6, and that seems to have fixed this issue, can't reproduce it anymore, thought the jumping text thing does still happen, but it's less noticeable.

Maybe you have multiple screens and you start the applications when the scaled screen is off but then turn the screen on when the apps already running?

no, i only use 1 screen (ny laptop's)

Sent from Proton Mail Android


-------- Original Message --------
On 2/24/25 3:20 AM, Ilya Fedin <bugzilla_noreply@kde.org> wrote:

>  https://bugs.kde.org/show_bug.cgi?id=479891
>  
>  --- Comment #112 from Ilya Fedin <fedin-ilja2010@ya.ru> ---
>  Maybe you have multiple screens and you start the applications when the scaled
>  screen is off but then turn the screen on when the apps already running?
>  
>  --
>  You are receiving this mail because:
>  You are on the CC list for the bug.

Were you able to patch qqc2-desktop-style via system.replaceDependencies like I proposed before? Can you try to add a `qWarning() << qApp->devicePixelRatio();` to the code calling QQuickWindow::setTextRenderType and look at what value you have actually?

Yes, i could and it did work, but i removed the patch once kde frameworks 6.9 landed. I'll look into doing that thing later

Sent from Proton Mail Android


-------- Original Message --------
On 2/24/25 10:12 AM, Ilya Fedin <bugzilla_noreply@kde.org> wrote:

>  https://bugs.kde.org/show_bug.cgi?id=479891
>  
>  --- Comment #114 from Ilya Fedin <fedin-ilja2010@ya.ru> ---
>  Were you able to patch qqc2-desktop-style via system.replaceDependencies like I
>  proposed before? Can you try to add a `qWarning() << qApp->devicePixelRatio();`
>  to the code calling QQuickWindow::setTextRenderType and look at what value you
>  have actually?
>  
>  --
>  You are receiving this mail because:
>  You are on the CC list for the bug.

(In reply to Ilya Fedin from comment #114)
> Were you able to patch qqc2-desktop-style via system.replaceDependencies
> like I proposed before? Can you try to add a `qWarning() <<
> qApp->devicePixelRatio();` to the code calling
> QQuickWindow::setTextRenderType and look at what value you have actually?

I get this as output when I open systemsettings using Konsole.

qt.multimedia.symbolsresolver: Couldn't load pipewire-0.3 library
qt.multimedia.symbolsresolver: Couldn't resolve pipewire-0.3 symbols
Using fontconfig file: "/home/stereomato/.config/fontconfig/conf.d/10-hm-fonts.conf"
2

You were saying it's not always reproducible, is this from the launch when it's reproduced?