When using plasma shell 5, fonts get corrupted in widgets which are scrollable when scrolling up or down. This issue affects (non exhaustive list): * removable devices widget (system tray) * software updates widget (system tray) * application starter Reproducible: Sometimes Steps to Reproduce: 1. run plasma-shell 2. open any widget with scrollable content (see list above) 3. scroll using your mouse wheel Actual Results: fonts sometimes (quite often) get misrendered. Note that after moving your mouse these rendering issues are often gone (in application starter and removable devices list; not in software updates widget). Expected Results: No font corruption.
Created attachment 96810 [details] software updates widget with corrupted fonts
Created attachment 96811 [details] device manager with corrupted fonts
I can confirm this issue as well. It has been long-standing, unfortunately. I will attach two more screenshots which show it rather prominently -- one from the application launcher and one from the desktop effects kcm. My experience is that this can only be triggered when scrolled via mouse wheel and that way it is 100% reproducible and happens all the time. For example: 1) Open the desktop effects kcm. 2) Scroll the list of effects one wheel unit down --> Font corruption happens If you scroll another wheel unit, everything looks fine again. Another wheel unit, and the font is garbled again. And so forth. I have tried to narrow this down but so far have failed. If there is anything I can do at all to help track this bug down, please let me know. I am seeing this on a fresh Gentoo x86_64 system w/ frameworks 5.25.0, plasma 5.7.4, Qt 5.6.1 and freetype 2.6.5. Xorg uses nvidia driver 370.23. KWIN Compositor is using OpenGL 3.1. But neither of those latter ones make any difference.
Created attachment 100846 [details] font corruption after one wheel unit in kcm desktop effects
Created attachment 100847 [details] font corruption after one wheel unit in application launcher
I forgot to mention: I also tested this with Qt's 5.6 git branch as of today -- the corruption is absolutely the same, even though a lot of font and scrolling related fixes went in after 5.6.1.
Meanwhile I have also tested this with a fresh OpenSuSE Tumbleweed Live iso in a virtual machine and the issue is also 100% reproducible there as well. I have also taken the liberty to report this upstream: https://bugreports.qt.io/browse/QTBUG-55638
Like expected, a minimal Qt example was asked for in the Qt bug report.
Since this also belongs here, I am copying and pasting from the Qt bug report where I just added the following: Ok, here what I have been able to debug: Everything that uses something inherited from Flickable (like ListView) will expose the issue. Scrolling will result in fractional positions for the content which will cause (severe) font corruption. Since Flickable defaults pixelAligned to false since its inception, those fractional positions are not rounded. Switching pixelAligned to true, fixes the corruption entirely, like expected. Most instances in KDE leave pixelAligned at its default, thus the widespread problem. As far as I know, subpixel positioning is currently only supported on Mac OS X. Questions remains, how are those fractional positions handled on other platforms – especially Linux? It seems like something is going terribly wrong and corrupting the glyph cache. Either way, I don't think fractional positions should result in a corrupted type face whatsoever... or any kind of corruption. Is there anything else I can do to further debug this and be of any help?
Created attachment 100867 [details] severe corruption in kickoff Here another example screenshot where the corruption was more severe... which is actually also the typical case. The corruption in the unscrollable area below (Computer, Leave, ...) won't be fixed by scrolling or re-opening the menu. Only "restarting" kickoff will fix it.
Like expected, this issue can be seen in other places as well. Pretty much everywhere where something inherited from Flickable is issued, like the Widgets browser (via "Add widgets...").
We have a dedicated Plasma ScrollArea used everywhere where we could just enable pixel alignment globally.
A quick grep revealed that apart from KWIN, a few other places still use ScrollView and would need adaptation as well to set the Flickable's pixelAligned=true to avoid the corruption. All things said though, this should not cause such a severe corruption after all. I have tried all morning long to debug what is going on in Qt but right now all I got is a head that is about to lift off from my shoulders. I hope the Qt devs do consider the bug report and won't leave it to rot. By the way, could someone set this to confirmed?
can also confirm this on Thumbleweed, took me a while to find this bug report, just glad its not only me getting irritated by it :)
(In reply to akm from comment #14) > can also confirm this on Thumbleweed, took me a while to find this bug > report, just glad its not only me getting irritated by it :) Thanks for reporting back here. It would be awesome if you could hop over to the Qt bug, give that qml minimal working example a try I posted there and report your findings as well as some system stats there as well. You can try the mwe by simply opening it with "qmlscene". Thanks so much in advance...
(In reply to Matthias Dahl from comment #15) > (In reply to akm from comment #14) > > can also confirm this on Thumbleweed, took me a while to find this bug > > report, just glad its not only me getting irritated by it :) > > Thanks for reporting back here. It would be awesome if you could hop over to > the Qt bug, give that qml minimal working example a try I posted there and > report your findings as well as some system stats there as well. You can try > the mwe by simply opening it with "qmlscene". Thanks so much in advance... done
Same problem here. Fresh install of openSUSE Leap 42.2.
(In reply to Ilya Bizyaev from comment #17) > Same problem here. > Fresh install of openSUSE Leap 42.2. see the link from Matthias: https://bugreports.qt.io/browse/QTBUG-55638 it needs to be fixed by QT it seems.
For some reason, this bug is not present in Kubuntu although is has the same Qt version.
*** Bug 375091 has been marked as a duplicate of this bug. ***
Could it be related to libinput? I found this post: https://forum.manjaro.org/t/kde-bad-font-rendering-when-scrolling/5175/2 but I didn't try suggested solution
(In reply to Dmitry Belyakin from comment #21) > Could it be related to libinput? The problem is with Qt -- and it has been located (= the commit that caused it and why it is happening). I have provided a patch as a stepping-stone (so to speak) to a final solution but thus far, I got no reaction at all on the Qt bug tracker. Personally, I use my patch without any problems but it is _definitely_ not a final solution. I am planning on revisiting this issue once I have some more free time on my hands -- and if it hasn't been fixed meanwhile. It is really a pity that this hasn't been addressed yet and remains an open issue, even though the cause has been located and a first patch was provided. :-(
This is a combo bug in both Qt's XCB backend and ScrollArea in QtQuickControls scrolling has two modes, moving by n pixels or by n "ticks". In QWheelEvent terms: - pixelDelta and angleDelta A libinput change has meant that Qt's detection of "is it a scroll wheel or not" is broken. I think libinput seems to trying to artificially say how far things should scroll at an input level rather than it being up to the application. In QXcbConnection::xi2HandleScrollEvent scrollingDevice.verticalIncrement is 15 . This matches what I see in xinput list which shows: Class originated from: 11. Type: XIScrollClass Scroll info for Valuator 2 type: 2 (horizontal) increment: 15.000000 flags: 0x0 We then go into the // We do not set "pixel" delta if it is only measured in ticks. if (scrollingDevice.horizontalIncrement > 1) rawDelta.setX(delta); In most Qt code this isn't a problem. Either pixel delta is ignored or it looks about right anyway In QtQuickControls QtQuickWheelArea we have a huge bug; as we now have valid pixelDelta we go into a different code path that ignores the user scrollspeed. It then randomly divides things by 2 to match some OS X behaviour. This is what leads to things being slow and corrupted fonts. I'll probably have to close this as upstream once I file a bug report there.
Upstream bug report: https://bugreports.qt.io/browse/QTBUG-59261
*** Bug 380248 has been marked as a duplicate of this bug. ***
Created attachment 105735 [details] fonts corrupted in desktop themes kcm Fonts corrupted in desktop themes kcm, see the screenshot. I use Arch, plasma 5.9.5.
*** Bug 388701 has been marked as a duplicate of this bug. ***
Found a workaround (for arch linux): 1. Install xf86-input-evdev 2. Create file /etc/X11/xorg.conf.d/10-evdev.conf (Delete existing if needed). 3. Put https://pastebin.com/Y5cePdTj in said file. 4. Reboot. Tell me if it worked :)
Hello Lorenzo Am on Tumbleweed, it has xf86-input-evdev installed. did a diff between the already installed /etc/X11/xorg.conf.d/10-evdev.conf and yours and they are a 100% match. So at least on Tumbleweed it's not a work around.
A fix is now in Qt in the 5.9 branch, but I don't think targetting 5.9.4 See https://codereview.qt-project.org/#/c/212398/
hi, it just reached Tumbleweed it seems as I am on libQT 5.10.0-3 and issue is gone as far as I can tell. Thank you
Fantastic news!
Still happens with Qt 5.11 on openSUSE Tumbleweed 20180625 ---- It happens with the Discover widget, Folder widget but not with Falkon, Konsole, Dolphin. A QML bug? Screenshot: https://i.imgur.com/bXDALSx.png The text will render correctly if I continue scrolling up/down some more pixels.
I think I've solved the problem by switching the touchpad driver from synaptic to libinput. You can close the bug if you want.
(In reply to idmresettrial from comment #34) > I think I've solved the problem by switching the touchpad driver from > synaptic to libinput. > > You can close the bug if you want. Your issue is more likely https://bugs.kde.org/show_bug.cgi?id=393202 Seems like the original issue is gone now, so I'll close this.