Hi, this is an attempt to summarize bug report 488108, which has become too noisy at this point. I am experiencing a font blurriness problem ever since I updated 6.0.4 to 6.0.5, as if antialiasing was off somehow. From the screenshots I'm going to share this might look like a barely noticeable issue, but IRL it really has an impact on the UX. Whichever KDE/plasma app I use on my external display now has blurry fonts, it looks a bit hazy as if my eyes were tired, which of course causes extra strain on might induce headaches etc. The only way to reliably make this issue objective/perceivable by others (short of having them sit in front of my screen), is to zoom in on some screenshots and focus on specific details. Specifically, I advise on concentrating on lower case letter "e" and its horizontal stroke, since it's the best metric I could find (but of course the blurriness is not limited to that character). Please follow the "e"s in the screenshots below. Zoom in as much as needed and you'll eventually see the difference (again, it looks subtle on screenshots, but trust me the issue exists and has a real impact on the overall UX even from .5 meters away) In the "bad" screenshots you will see the horizontal stroke is a blur of TWO horizontal rows of pixels. In the "good" screenshots you will see that this stroke is made of a SINGLE horizontal row of pixels -> this provides for a sharp, well rendered font Now some bullet point recap: - Problem only affects the fonts within the "content" areas of KDE apps (and plasma widgets, e.g. Application launcher). The title bars are strangely NOT affected - I can only reproduce this with a dual monitor setup, and when scaling is applied as follows: - Both displays at 100% -> no problem - *Internal* (laptop) display scaled (e.g. 120%), external 100% -> fonts on *external* display blurry - External display scaled (e.g. 120%), internal 100% -> no problem - Both displays scaled (e.g. 120%) -> no problem - bottom line, this is never visible on the internal display, but it is on the external one, depending on the *internal's* scaling - I can easily capture side-by-side screenshots of the issue by: - opening a KDE app (e.g. Dolphin) with my starting conditions on the internal display's scaling factor - changing internal display's scaling factor - open another instance of the same app and put it side by side with the previously opened instance - for Plasma workspace screenshots (e.g. Application Launcher widget), since I can't "run" another plasma "window" I just capture a screenshot before, then do a systemctl --user restart plasma-plasmashell.service, reopen the widget and capture the second screenshot - This started happening since upgrading 6.0.4 to 6.0.5 - I'm using Wayland, haven't tried with an X11 session - Things tried (no success): https://bugs.kde.org/show_bug.cgi?id=488108#c6 I'm posting links to a screenshot selection from 488108 (please remember the "e" rule): - Application launcher compared with different scale factors -> blurry: https://bugsfiles.kde.org/attachment.cgi?id=170944 not blurry: https://bugsfiles.kde.org/attachment.cgi?id=170945 - Kate compared with different scale factors: blurry in the window at the top, crisp in the one at the bottom: https://bugsfiles.kde.org/attachment.cgi?id=170943 - close-up photos with different scale factors + systemctl restart plasma: crisp: https://bugsfiles.kde.org/attachment.cgi?id=171070 blurry: https://bugsfiles.kde.org/attachment.cgi?id=171069 - Title bar crisp, content blurry, proving that even when reproducing the issue, the title bar fonts are NOT affected. Taking Konsole as an example: https://bugsfiles.kde.org/attachment.cgi?id=171227, but also visible on Kate: https://bugsfiles.kde.org/attachment.cgi?id=171225 and Dolphin: https://bugsfiles.kde.org/attachment.cgi?id=171226 Feel free to read the whole history/attachments in report 488108. I had reported 488108 under kwin but I'm putting this one under general, since I don't know if the problem comes from some KDE framework module, some external dependency (QT), or who knows what, so please I ask KDE devs to categorize as they see fit.
Created attachment 172117 [details] Side by side different KDE apps Kate, Konsole, Dolphin, are all affected (again check the "e"s, don't hesitate to zoom in A LOT, several hundreds %)
Created attachment 172118 [details] zoom in from previous screenshot attachment 172117 [details] This is a zoom-in for https://bugs.kde.org/attachment.cgi?id=172117 (the Kate quadrant). Notice how the window at the top has smooth "e" both in the Title bar and the Menu bar, while the one below has smooth "e"s only in the Title bar, and blurry ones in the Menu bar. Window above was created while scaling was set to 100% on both displays. Window below was created after changing scaling of internal display to 120%.
*** Bug 488108 has been marked as a duplicate of this bug. ***
I'll see if I can reproduce it soon.
I can reproduce this issue. It's quite consistent. Simplified steps to reproduce: 1. Have two screens 2. Scale one of them to something higher than 100% 3. Open a KDE app on the 100% scale screen 4. Take a screenshot of text in the main view 5. Zoom in on the screenshot in Gwenview The text is indeed blurrier and exhibits worse pixel alignment than it does when both screens are at 100%. Might be a KWin, Qt, or Wayland protocols bug. Moving to KWin for further triage.
Created attachment 172148 [details] "Steve" text in Dolphin with both screens at 100% scale
Created attachment 172149 [details] "Steve" text in Dolphin with one screen at 100% scale and one at 225% scale
Nate, you made my day! It was great to see your reply. Reproducing is the first step for squashing it 🤞
*** Bug 491491 has been marked as a duplicate of this bug. ***
Hi, is there any progress on this? This is currently stopping me from using per-monitor scaling.
*** Bug 492102 has been marked as a duplicate of this bug. ***
Hello, just chiming in to ask if there are any updates on this. Right now my laptop display is forced to 100% because of this making the text so small it's unreadable - basically I'm working on my external display only because of that. Would be great to have this fixed so that users can unleash the full potential of multi-monitor setups. Thanks!
Yes, its being analyzed, and so far we've traced it to a Qt change. Apparently a commit that fixed a bug revealed this issue, because the old buggy state that got fixed happened to look better due to another bug! A fix is in progress.
(In reply to Nate Graham from comment #13) > Yes, its being analyzed, and so far we've traced it to a Qt change. > Apparently a commit that fixed a bug revealed this issue, because the old > buggy state that got fixed happened to look better due to another bug! A fix > is in progress. Sounds great! Thanks for this update.
So basically, this was caused by https://invent.kde.org/qt/qt/qtbase/-/commit/e7ddd490cf44ecd1c59b3798294ed2812fc5a940, which was made to fix https://bugreports.qt.io/browse/QTBUG-122910, which was reported against fractional scale factors. It looks like the change broke integer scale factors. It's also not 100% clear that it fixed the bug with fractional scale factors, either. We're following up upstream and will make sure this gets fixed.
*** Bug 492918 has been marked as a duplicate of this bug. ***
> We're following up upstream and will make sure this gets fixed. Are there any links to such discussion? I just can't believe there's any work on that as I monitor Qt's scaling situation for a long time and to my knowledge this isn't a bug but an intentional restriction of Qt's HiDPI and font rendering system design. It scales fonts with QPainter and so couldn't apply hinting nor know what's the scale of the exact window it renders to. So it's either no HiDPI or no hinting. Qt's upstream suggestion has always been to disable HiDPI if you really need hinting. I even created https://bugreports.qt.io/browse/QTBUG-111380 a long time ago because Qt 6 doesn't let disable it. If you would search their bugtracker, there are lots of bug reports which are essentially duplicates to the lack-of-hinting problem.
Forgot to mention: and all these reports either have radio silence or explanation that it's intended behavior.
(In reply to Ilya Fedin from comment #17) > > We're following up upstream and will make sure this gets fixed. > > Are there any links to such discussion? I just can't believe there's any > work on that as I monitor Qt's scaling situation for a long time and to my > knowledge this isn't a bug but an intentional restriction of Qt's HiDPI and > font rendering system design. It scales fonts with QPainter and so couldn't > apply hinting nor know what's the scale of the exact window it renders to. > So it's either no HiDPI or no hinting. Qt's upstream suggestion has always > been to disable HiDPI if you really need hinting. I even created > https://bugreports.qt.io/browse/QTBUG-111380 a long time ago because Qt 6 > doesn't let disable it. If you would search their bugtracker, there are lots > of bug reports which are essentially duplicates to the lack-of-hinting > problem. Wouldn't that mean that this would only affect Qt applications? I can reproduce this issue on all applications, even on GTK ones.
To my knowledge, GTK attempts to move to subpixel positioning that conflicts with hinting. In 4.16, they even stopped inheriting existing font settings by default (you first have to enable the manual mode via the new font-rendering gsetting). If you use fractional scaling, what you see might just be because gtk3 doesn't support fractional scaling and thus the windows get downscaled from the next integer scale factor. I.e., yes, both toolkits seem to move out of supporting hinting
In case of gtk, it also doesn't support rgb antialiasing since the ngl renderer (somewhere 4.x). And Plasma doesn't seem to synchronize font settings to gtk (https://bugs.kde.org/show_bug.cgi?id=487714) so unless you manually set gsettings and XSETTINGS, you will get gtk default.
I think it's also worth mentioning https://bugreports.qt.io/browse/QTBUG-122830 that leads to blurry font in Quick applications with fractional scaling (but not Widgets ones). It's present on both Wayland/X11 but doesn't seem to happen on Windows (which is perhaps why it has no attention).
> so unless you manually set gsettings and XSETTINGS, you will get gtk default Just checked xrdb -query, it has hinting settings set so gtk applications run via X11/Xwayland do in fact get them. Only GTK on Wayland is not synchronized.
(xrdb controls Xresources, a thing similar to XSETTINGS but still a different one)
Hi, I just re-tested this today by setting my internal display scale factor to 125% (I had to run it at 100% so far to work around the problem). The problem is still there, as per screenshot (check the horizontal strokes of lower-case letter "e" at a very high zoom level, e.g. 600+%).
Created attachment 175107 [details] blurry font when internal display uses fractional scale factor left: screenshot of a Dolphin window opened while internal display was scaled at 100% right: screenshot of a Dolphin window opened after setting internal display scaling to 125% (and triggering the bug) Notice how in "Documents" the horizontal stroke for letter "e" is a single line of pixels on the left, while it's a bunch of blurred lines on the right
(In reply to Andrea Ippolito from comment #26) > Created attachment 175107 [details] > blurry font when internal display uses fractional scale factor > > left: screenshot of a Dolphin window opened while internal display was > scaled at 100% > right: screenshot of a Dolphin window opened after setting internal display > scaling to 125% (and triggering the bug) > > Notice how in "Documents" the horizontal stroke for letter "e" is a single > line of pixels on the left, while it's a bunch of blurred lines on the right Sorry, forgot system info: Operating System: openSUSE Tumbleweed 20241018 KDE Plasma Version: 6.2.1 KDE Frameworks Version: 6.7.0 Qt Version: 6.8.0 Kernel Version: 6.11.3-1-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics Memory: 30.7 GiB of RAM Graphics Processor: AMD Radeon 780M Manufacturer: Framework Product Name: Laptop 13 (AMD Ryzen 7040Series) System Version: A7
It seems it was closed not because it's fixed but because it's not a real bug (RESOLVED UPSTREAM rather than RESOLVED FIXED)?
(In reply to Ilya Fedin from comment #28) > It seems it was closed not because it's fixed but because it's not a real > bug (RESOLVED UPSTREAM rather than RESOLVED FIXED)? So today a KDE Plasma user with a high-res internal display needing a fractional scale factor needs to suffer blurry fonts everywhere? That seems unacceptable to me, especially because it used to work fine on 6.0.4. Are there any workarounds possible?
You can't really work around that any other way than switching away from Linux, Both Qt and GTK seem to abandon hinting in sake of hidpi. The Qt bug report mentioned by Nate even got a response from a Qt dev explaining that this is intetional (like they did in older reports I was talking about in my previous comment): > The background for this is that hinted text layouts are not linearly scalable, so when there is a scale set on the UI, then hinting has to be disabled, since the text layout is done in logical coordinates and then rendered at a different size later.
That it worked on 6.0.4 was a bug that was leading to font distortions, due to not considering Wayland in the check. On almost all other platforms (X11, macOS), Qt doesn't hint with HiDPI. The only exception as far as I know is Windows, where they decide to do either light hinting or no hinting based on text size. But that also doesn't work as intended and leads to font distortions: https://bugreports.qt.io/browse/QTBUG-100774
So if I got this right, I'm better off disabling font hinting entirely when using fractional scaling and hidpi, and work with fonts that still render well without any hinting? Would that be the recommended way forward, for a user with hidpi + fractional scaling who wants sharp fonts? Thanks
No, font hinting is disabled automatically by Qt and that's why fonts seem blurry to you. If you will disable font hinting in settings,, you will likely see the same blurriness even without scaling enabled.
(In reply to Ilya Fedin from comment #33) > No, font hinting is disabled automatically by Qt and that's why fonts seem > blurry to you. If you will disable font hinting in settings,, you will > likely see the same blurriness even without scaling enabled. In other words, there's no workaround to this bug? Wasn't fractional scaling one of the main "selling" points of Wayland?
That's not about fractional scaling btw but about scaling in general. That's just how Qt handles it. And that's not specific to Wayland, it's the same on X11 (but I guess you don't see it there because you can't specify different scale factors to different screens). You can try to use software on a different toolkit but I'm afraid that the only toolkit with crisp fonts on Linux with scaling might be Chromium/Electron.
Closing as upstream again, as this is a Qt bug that we can't do anything about in any KDE code, unfortunately. We need the Qt folks to get religion and support hinting and scaling simultaneously.
(In reply to Ilya Fedin from comment #33) > No, font hinting is disabled automatically by Qt and that's why fonts seem > blurry to you. If you will disable font hinting in settings,, you will > likely see the same blurriness even without scaling enabled. I tried and indeed couldn't see any improvements even without scaling. > You can try to use software on a different toolkit but I'm afraid that the only toolkit with crisp fonts on Linux with scaling might be Chromium/Electron. Well that's a bummer :( > We need the Qt folks to get religion and support hinting and scaling simultaneously. 🤞
(In reply to Ilya Fedin from comment #35) > That's not about fractional scaling btw but about scaling in general. That's > just how Qt handles it. And that's not specific to Wayland, it's the same on > X11 (but I guess you don't see it there because you can't specify different > scale factors to different screens). You can try to use software on a > different toolkit but I'm afraid that the only toolkit with crisp fonts on > Linux with scaling might be Chromium/Electron. In my findings, electron applications had the same blurry text as all else
It's likely that you don't have gtk font settings set. Ensure that xrdb -query provides right values for Xwayland applications. Additionaly, you have to manually set font settings for gtk wayland via dconf-editor.
> Additionaly, you have to manually set font settings for gtk wayland via dconf-editor. or via gnome-tweaks (just remembered) which might be a more user-friendly way > We need the Qt folks to get religion and support hinting and scaling simultaneously. I think you will have a very hard time. Even in the last message on the Qt bug report Eskil seem to say about supporting hinting only on unscaled screens when scaling is globally enabled and only if they have the required mechanics in place to determine the correct dpi. But the last time I looked at the code (somewhere in summer iirc), it still wasn't the case so I guess the Qt bug report will either remain in unsolved state for near-forever or will get closed. > we can't do anything about in any KDE code That's false, by the way. You can get your own font rendering and use it instead of QPainter::drawText. Yeah, that's very hard but not impossible.
I've been forced by circumstance to start (mostly) liking unhinted fonts on high DPI displays. The reality is that it will likely take most of these toolkits a long time to fix their code, if at all. Many devs falsely believe that "hinting doesn't matter anymore on high DPI displays" which is arrogant and naive. Each group has some excuse why it can't be implemented which is amusing given that it works just fine in Chrome and older GTK versions. There is no technical reason it can't work; it's that developers choose not to implement it properly. I've settled on using browsers that respect hinting when configured correctly (vivaldi, chromium, brave, firefox), and use applications that do when possible (mate-terminal, thunar file manager, thunderbird, etc.). For cases where it doesn't work properly (KDE Plasma) it's usually possible to find a UI font (and size) that minimizes the appearance of blurriness and fringing, but you have to play around.
Hm, maybe Plasma just needs a default font that looks better without hinting? Honestly, personally I use slight/no hinting for quite a long time on not-so-hidpi display (135% scaling) and don't understand all these complaints about blurry rendering. I use Exo 2 font, btw.
(by slight/no hinting I mean that I have default font rendering settings that have hintslight set but Qt apps have no hinting due to scaling)
(In reply to Ilya Fedin from comment #42) > Hm, maybe Plasma just needs a default font that looks better without > hinting? Honestly, personally I use slight/no hinting for quite a long time > on not-so-hidpi display (135% scaling) and don't understand all these > complaints about blurry rendering. I use Exo 2 font, btw. I'm also using Slight hinting as per KDE System Settings, but the blurriness is quite visible to me. I use Inter Display, will give Exo 2 a try
Hi everyone, just read Nate's weekly post on kde blogs this morning, fractional scaling improvements got me excited! But I can't stop thinking of this issue, since to this day it's sti effectively a regression from an end user experience, to the point it's making me prefer no scaling at all - that's how annoying/headache-inducing those blurry fonts are for me. That's why I wanted to ask if there's an issue/bug reported on QT side to track this. As users/clients of QT, I would guess that KDE could express some kind of wishlist for features that would be nice to have. I'm referring specifically to: Closing as upstream again, as this is a Qt bug that we can't do anything about in any KDE code, unfortunately. **We need the Qt folks to get religion and support hinting and scaling simultaneously.** (comment 36 https://bugs.kde.org/show_bug.cgi?id=491015#c36) Sorry for the spam, and thanks
> to the point it's making me prefer no scaling at all - that's how annoying/headache-inducing those blurry fonts are for me Yeah, I tried to disable scaling too and was shocked how much better font rendering became to me. After that, I made a hand-made text (DPI) scaling. It's sad the option was removed from system settings UI, it's perfect for my single screen use case. So I did the following: 1. Set QT_ENABLE_HIGHDPI_SCALING=0 2. Set QT_FONT_DPI=the DPI you want (I use 136, that's 96*1.42 - my font becomes way better rendered since this value, with standard 10pt size) 3. Added into ~/.config/kded5rc [Module-gtkconfig] autoload=false This disables updating GTK settings - to override them: 4. Xft/DPI and Gdk/UnscaledDPI in ~/.config/xsettingsd/xsettingsd.conf - the DPI you want * 1024 (139264 in my case) 5. /org/gnome/desktop/interface/text-scaling-factor on dconf - the scale factor you want (1.42 in my case) 6. Create an autostart entry with bash -c 'echo Xft.dpi: the DPI you want | xrdb -merge' kde-gtk-config also sets the DPI into ~/.config/gtk-4.0/settings.ini, ~/.config/gtk-3.0/settings.ini, ~/.gtkrc-2.0 but I haven't changed them cause they get overridden by xsettingsd anyway This has improved not only Qt apps for me but also firefox. > That's why I wanted to ask if there's an issue/bug reported on QT side to track this. Look at the URL field of the bug report, it has https://bugreports.qt.io/browse/QTBUG-129731. It seem to even have a patch in review but then they say in it they're going to re-introduce text rendering artifacts on scaled screens if the primary screen is unscaled to fix hinting on the unscaled one, as a trade-off. 😭 The Qt bug tracker also has another report: https://bugreports.qt.io/browse/QTBUG-128874. The difference between those seem to be that the first is perceived by Qt devs as "fixing the hinting only on unscaled screens" while this one "fixing the hinting on all screens". That's only the newest ones, though. The Qt bugtracker has lots of older ones but it's not easy to find them straight away.