Hello, since upgrading from 6.0.4 I have immediately noticed that the fonts on my external monitor are not as sharp as they used to be. I can't tell if it's also the case on my internal display since it has a higher resolution, and it's harder to notice there, but on the external one it's definitely noticeable. 6.0.4 https://discuss-cdn.kde.org/uploads/default/original/2X/3/30a43445bd0420c40d7a4817f8cee44d095b5274.jpeg 6.0.5 (notice how ugly the horizontal stem on the "e" looks, compared to the previous version https://discuss-cdn.kde.org/uploads/default/original/2X/7/7cf5fec2d0df2c616448082d72eaf17d35ef8195.jpeg I have also opened a topic here: https://discuss.kde.org/t/font-rendering-regressed-with-6-0-5/16677/2 My setup is a Wayland session, dual monitor, the external being the main one @100%, the laptop being the secondary @125%. Operating System: openSUSE Tumbleweed 20240531 KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.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 Graphics Manufacturer: Framework Product Name: Laptop 13 (AMD Ryzen 7040Series) System Version: A7 Thanks!
Were there any other system upgrades that happened at the same time? For example anything from Qt? Because font rendering in apps is generally something that comes from the toolkit, not any KDE code. Looking through the KWin commits visible at https://kde.org/announcements/changelogs/plasma/6/6.0.4-6.0.5/, I see one thing that *maybe* could have caused this if you're using a fractional scale factor: https://invent.kde.org/plasma/kwin/-/commit/6f224350961453b286b4865798a624f3560bde01 Are you using a fractional scale factor? And if you are, does the problem go away if you change the scale factor to 100% or 200%? And if it does, are you able to test KWin with that commit reverted?
(In reply to Nate Graham from comment #1) Thank you so much Nate for your reply! > Were there any other system upgrades that happened at the same time? Definitely, but it would honestly be quite hard to figure out what else has changed. I have a btrfs snapshot taken with snapper listing all the differences, I doubt it's of any use but I have the textual diff if needed (40MBs of fun!) I know that Linux allows for some font config by symlinking stuff from /usr/share/fonts-config/conf.avail (among others) to /etc/fonts/conf.d/ A couple of files were added there during the update, and the others stayed the same. Still, just to rule out this change to be the cause of the problem, I took the state of the "good" snapshot (which I booted into to check how the symlinks looked like) and applied it to the running/latest/6.0.5 snapshot, then rebooted and...still blurry. So that's not it. > For > example anything from Qt? Because font rendering in apps is generally > something that comes from the toolkit, not any KDE code. Looking through the > KWin commits visible at > https://kde.org/announcements/changelogs/plasma/6/6.0.4-6.0.5/, I see one > thing that *maybe* could have caused this if you're using a fractional scale > factor: > https://invent.kde.org/plasma/kwin/-/commit/ > 6f224350961453b286b4865798a624f3560bde01 > > Are you using a fractional scale factor? And if you are, does the problem go > away if you change the scale factor to 100% or 200%? I definitely am, but following your prompt I did some additional tests. I have a dual monitor setup where the external is unscaled, but the laptop one is at 125%. The problem happens also on the unscaled one. I initially ruled out fractional scaling as a possible cause, because I had reproduced the problem immediately after setting the laptop back to 100%. What I didn't think to do, though, was (please don't hate me :D ) to close and reopen the app (Kate in this case), in order to see the effects of the scaling change. Or restarting the plasmashell for every other part of the UI (`systemctl --user restart plasma-plasmashell.service`). If I had done that, I would've noticed that fonts immediately look GREAT again. > And if it does, are you able to test KWin with that commit reverted? I would gladly try. I have an 8 core CPU that can take some more compiling :) Would you be so kind as to point me to the recommended documentation on how to build from source and run this? Thanks!
Created attachment 170234 [details] side by side dolphin
Additional info: even at 200% the issue shows. 100% on all displays is really the only way to get perfectly crisp fonts. In the attachment, on the LHS a Dolphin window I have opened after restoring 100% everywhere, on the RHS another Dolphin I launched after setting the laptop back to 125% (my daily config).
Imma try this https://community.kde.org/KWin/Building
Hi again Nate, I have finally managed to build kwin without the change brought by the commit you mentioned (6f224350961453b286b4865798a624f3560bde01), but unfortunately the problem's still there. I'll mention the steps I followed just in case you notice something wrong - I couldn't find a way to be sure I was actually running the modified source. I cloned kdesrc-build, then launched a build via `kdesrc-build kwin`. This cloned all the dependencies (master branches and ultimately built kwin - master branch as well). So I undid the change of that commit, and launched again `kdesrc-build kwin` but this time with the `-S` flag to skip pulling from git repos, to make sure my change was not being undone by a pull. I then replaced my running kwin via `<build_dir>/usr/bin/kwin_wayland --replace`, this restarted kwin, and the issue was still reproducible. I even went as far as checking out the tag `tags/v6.0.4` of kwin and followed the same step to replace, and before doing so launched a `<build_dir>/usr/bin/kwin_wayland --version`, which output 6.0.4 as expected, but the problem was still there. So at this point I don't know if the problem comes from elsewhere, or if I have inadvertently failed to actually run the version of kwin I built. Is there anything else I can try, do you have other ideas? Thanks
It sounds like you did it right. Any ideas what might be going on here, KWin folks?
(In reply to Andrea Ippolito from comment #6) > So at this point I don't know if the problem comes from elsewhere, or if I > have inadvertently failed to actually run the version of kwin I built. "to replace" -> to reproduce Autocorrect...
I too have the impression that fonts with KDE 6.0.5 are not as "crisp" as they used to be. I am running Fedora 40 with a HiDPI screen (3840x2160) with the scaling factor set to 175%. KDE Plasma Version: 6.0.5 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 Graphics Platform: Wayland Graphics Processor: Mesa Intel® HD Graphics 620
(In reply to spam_eater from comment #9) > I too have the impression that fonts with KDE 6.0.5 are not as "crisp" as > they used to be. > > I am running Fedora 40 with a HiDPI screen (3840x2160) with the scaling > factor set to 175%. > > KDE Plasma Version: 6.0.5 > KDE Frameworks Version: 6.3.0 > Qt Version: 6.7.1 > Graphics Platform: Wayland > Graphics Processor: Mesa Intel® HD Graphics 620 Update. This seems to be fixed for me on the neon-unstable build of 20240520 (running KDE Plasma 6.0.90, but I guess this is just the alias for "next"). If you don't mind downloading the ISO and trying it out, I think that your feedback would also be useful. The only remaining question for me is whether that version I tried via neon-unstable is gonna be included in 6.1 or not, given the build date I really hope so. If you don't mind Nate I'll wait until 6.1 hits my distro (Tumbleweed, shouldn't take long) and report back to confirm 6.1 fixes it.
I just got the update to 6.1 and things look good again. Here are the version details in case this interesting: Operating System: Fedora Linux 40 KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 Kernel Version: 6.9.4-200.fc40.x86_64 (64-bit) Graphics Platform: Wayland Graphics Processor: Mesa Intel® HD Graphics 620
Hi, I received 6.1.0 yesterday with my distro (Tumbleweed), and weirdly enough, the issue is still there. I'm attaching a screenshot of a Kate instance (above) that I opened while my laptop was scaled to 125%, and another one (below) that I opened after setting it back to no scaling. As you can see, the text on the window below is significantly less blurry. This is also very visible in the Plasma Shell, before and after changing the scaling on the laptop display and restarting it via `systemctl --user restart plasma-plasmashell.service`, as per screenshots attached.
Created attachment 170943 [details] 6.1.0-kate-blurry Kate above (blurry) was opened while running my Wayland session with a dual monitor, with the external at 100% and the laptop one at 125%. Kate below (crisp) was opened in my Wayland session with the same setup, but after having set the laptop display back to 100% scaling.
Created attachment 170944 [details] app-launcher-blurry With laptop scaled to 125%
Created attachment 170945 [details] app-launcher-crisp With laptop scaled to 100%
I did some more testing and: - KDE Neon User (the 20240624-1012 ISO) works fine. Fonts are perfectly crisp even when my laptop is set to 125% - Fedora 40 fully updated as of 25/06 IS affected - TW snapshot 20240622 IS affected I even copy pasted all the font configs I could find in the Neon live image (both in /etc and /usr) and copied that into my TW install, after clearing any font config my install was providing. Still fonts were blurry. At this point I suspect that the problem might be elsewhere, e.g. mesa drivers (?). KDE Neon uses 23.2.1, TW and Fedora use 24.1 I'm curious tho as to way another user on FC40 says it looks fine again after 6.1.0
(In reply to spam_eater from comment #11) > I just got the update to 6.1 and things look good again. > > Here are the version details in case this interesting: > > Operating System: Fedora Linux 40 > KDE Plasma Version: 6.1.0 > KDE Frameworks Version: 6.3.0 > Qt Version: 6.7.1 > Kernel Version: 6.9.4-200.fc40.x86_64 (64-bit) > Graphics Platform: Wayland > Graphics Processor: Mesa Intel® HD Graphics 620 Hi! As per my latest message, I can still reproduce on FC40 running 6.1.0 Since you can't, would you be so kind as to provide screenshots of the Kate (or Kwrite) menu bar? One to be taken with scaling set to 100% on every display -> please launch Kate/Kwrite AFTER setting this display config Another one to be taken with scaling set to 125% on one of your displays -> please launch Kate/Kwrite AFTER setting this display config Thanks!
I genuinely can't see the problem in those screenshots, unfortunately. Generally I consider myself reasonably sensitive to this issue, but what the screenshots show is more subtle than what I can detect. It does sound like perhaps driver or Qt version differences might help explain this.
It's subtle indeed, but after having had the "crisp" version day in day out, the difference is immediately noticeable to me. You can refer to the 6.1.0 Kate attachment and compare the horizontal strokes on lower case "e" and "t"s. The crisp version has clearer strokes while the other one has them more blurred. A photo would make it more visible, maybe, I can attach one tomorrow. As for understanding where the issue comes from, I'd really like to help but I'd need a way to mix and match different versions of the kernel and plasma so that I can try and isolate the root cause. I still have the diff between my system's snapshots when going from 6.0.4 to 6.0.5, the kernel was also updated on that occasion. But I lack the skill to and distro to try out several combinations of kernel/qt/plasma. I wonder if Nixos could help in that regard. If you have any ideas, please share :) Thanks
Got it. It was more subtle than I was used to, but I see it now. FWIW Kate doesn't using QtQuick, so there's a whole different codepath for anything it draws on the screen compared to bugs like Bug 479891. I heavily suspect this is a Qt issue.
(In reply to Nate Graham from comment #20) > Got it. It was more subtle than I was used to, but I see it now. > > FWIW Kate doesn't using QtQuick, so there's a whole different codepath for > anything it draws on the screen compared to bugs like Bug 479891. I heavily > suspect this is a Qt issue. It's not just Kate, though. I can see the same problem on the entire shell. On Kate it's easier to reproduce because all I need to do is re-enable fractional scaling and open a new instance, and I'll be able to capture a side-by-side screenshot with the (crisp-looking) instance that I opened while scaling was set to 100%. But I can reproduce it as well on the entire plasmashell by restarting the user service. I'm attaching a couple of close-up shots, you can clearly see that the "e" in Firefox exhibits the same problem. Since this looks like a tricky issue to pinpoint, I was wondering if a chat interaction with KDE devs could be more productive. There are several factors at play and I think that quite some combinations need to be tested, which I'm totally willing to, but without expert guidance and quick interactions I'm not going anywhere :( Is there a matrix chat where KDE devs hang around (possibly someone already familiar with this issue)? Thanks :)
Created attachment 171069 [details] blurry-scaling-enabled Lower case "e" in Firefox has a horizontal stroke which is ~2px high making it look blurry (from farther away)
Created attachment 171070 [details] crisp-scaling-disabled Lower case "e" in Firefox has a horizontal stroke which is exactly 1px high making it look crisp (from farther away)
Update, I found something interesting. It seems that the blurriness regression only affects the menu bar. The title bar is fine. This goes for Kate, Konsole, Dolphin... As always, focus on the horizontal strokes of letter "e" in my screenshots. Sometimes they are well defined (one pixel high), others they are blurry (like 2 pixel high but grey-ish)
Created attachment 171225 [details] title bar crisp, menu bars blurry External display 100%, internal display 120% - Wayland session Plasma/Frameworks/QT 6.1.1/6.3.0/6.7.2 This screenshot captures 2 overlapping Kate windows. For the one in the back I only captured a portion of the menu bar. Notice how the "e" in "View" is blurry The overlapping Kate window shows the same blurriness in its own menu bar (notice the "e" in "Sessions". However, the "e" in the titelbar (word "Untitled") is rendered differently and looks crisp.
Created attachment 171226 [details] dolphin title bar crisp, internal UI component blurry As in the previous attachment. Notice how the "e" in the titlebar (word "Home") has a crisper horizontal stroke, compared to the one in the internal UI component of the Dolphin window (words "home" and also "Name" for the column header)
Created attachment 171227 [details] konsole title bar crisp, menu blurry another example
Hi Nate, I had an eureka moment earlier when I looked at a perfectly crisp titlebar in Kate, while running my laptop display scaled, which usually caused the issue. I thought I was crazy. But actually this made me realize (and I hope this can be helpful for the investigation), that the text in titlebars is unaffected. The blurriness only happens inside the app content, not on the window decorations. And it's the case for several KDE apps (I have only tested/screenshotted Kate, Dolphin and Konsole). I hope this can guide the investigation in the right direction. Thanks, and please let me know if I can help further
(In reply to Andrea Ippolito from comment #28) > Hi Nate, > > I had an eureka moment earlier when I looked at a perfectly crisp titlebar > in Kate, while running my laptop display scaled, which usually caused the > issue. > > I thought I was crazy. But actually this made me realize (and I hope this > can be helpful for the investigation), that the text in titlebars is > unaffected. The blurriness only happens inside the app content, not on the > window decorations. > > And it's the case for several KDE apps (I have only tested/screenshotted > Kate, Dolphin and Konsole). > > I hope this can guide the investigation in the right direction. > > Thanks, and please let me know if I can help further Kindly refer to the 3 attachments I added earlier today (not sure I explained myself well in this comment :D )
Created attachment 171268 [details] diff introducing the problem I'm posting this because I may need to reinstall my system from scratch in the upcoming days and will lose the precious snapshot information, therefore I dumped a diff between the states of my system when running Plasma 6.0.4 and when running 6.0.5 after taking the update
Created attachment 171406 [details] dolphin context menu looking awful Same problem in Dolphin's context menu (but also all other views/panels)
Hi Nate, this is nearing its month-versary, do you know if there are any clues about the cause for this regression? It's really unfortunate that KDE provided MacOS levels of font crispiness and now it's back to the middle ages :( I hope this bug doesn't become irrelevant eventually, to the point where we just have to live with this huge downgrade. Thanks for your patience and sorry for bothering
Created attachment 171407 [details] font rendering QT vs GTK Again focus on the 'e' horizontal stroke I think this might be a QT regression...
Hi again, as I've failed to find someone knowledgeable on the Matrix chat, I'm just chiming in again here, in the hopes that someone has an idea about what introduced this regression :( IMO both the UX and KDE as a whole take a big hit from this, as it screams "unpolished", especially for folks trying out Linux/KDE for the first time. Thanks
Hi Nate, I felt like this report had grown so large, it was hard for anyone to action. Therefore I have summarized the main points in this new report: https://bugs.kde.org/show_bug.cgi?id=491015 Hope I did a good job at that and that someone can look into it/has an idea about what's going on. Closing this one. Thanks! *** This bug has been marked as a duplicate of bug 491015 ***