https://bugs.kde.org/show_bug.cgi?id=500683
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #16 from [email protected] --- Hey all. This one kept bugging me, so even though I don't really know how Qt's text rendering works, I dug in. I think I found the actual cause, plus a workaround that makes the desktop labels sharp until a proper fix lands in Qt. I'm just a user, not a maintainer or a graphics person, so corrections are very welcome. CAUSE (As far as I can tell) Desktop icon labels are PlasmaExtras.ShadowedLabel, and that component puts layer.enabled plus a Qt5Compat DropShadow on the label itself. DropShadow then draws the visible text too, from the layer's texture, with linear filtering. At a fractional scale the texture is a whole number of pixels but its spot on screen usually isn't, so the text gets resampled and comes out soft. Panel labels have no layer, which is why it only shows up on the desktop. David asked on MR 3678 whether it was "Just the ShaderEffect on the ShadowedLabel?" I think the answer is yes. MR 3678 aligned the icon positions to device pixels, which helps, but the label's own bounds and its padded texture can still land between pixels, because Qt rounds the texture size without snapping where it lands. A label's position and width both feed into that, which fits the "only some columns" pattern in this report. TESTING I compared stock and patched labels on a real KWin Wayland desktop in two setups: - Plasma 6.8.1 / Qt 6.12.0 in a QEMU VM (KWin on vkms, software GL) - Plasma 6.7.5 / Qt 6.11.2 on Fedora 44 Kinoite with an NVIDIA GPU (nested KWin) The numbers are the share of label text pixels that stay near-white, which drops when text is blurred. The two setups scored slightly different regions, so compare stock against patched within each setup, not across setups. scale VM stock VM patched NVIDIA stock NVIDIA patched 100% 0.16 0.14 0.39 0.39 125% 0.01 0.26 0.08 0.44 150% 0.03 0.25 0.54 0.54 175% 0.15 0.39 0.36 0.64 200% 0.86 0.86 0.67 0.67 At 150% every label in the row was sharp on the 6.7.5 machine and blurry in the 6.8.1 VM. I haven't figured out why. The 6.7.5 machine logged QtRendering at 150%, and the 6.8.1 source points to the same in the VM (I didn't log it there). Stock also stayed sharp on 6.7.5 with NativeRendering forced, so the render type doesn't look like the explanation. I didn't see any change outside the labels in these captures, and on the 6.7.5 machine the 125% and 175% results hold with NativeRendering forced on the label too. See atachments: - compare-1.25.png (stock on top, patched below) - compare-2.png (an integer-scale control) - libplasma-shadowedlabel.diff. PROPOSAL The label draws its own text, and the shadow comes from a GaussianBlur of an invisible copy behind it, so only the shadow goes through a texture. At 100% and 200% it closely matches what you get today, though it isn't pixel-identical everywhere. Porting the current label to MultiEffect wouldn't fix this on its own, since MultiEffect also draws the text from an unsnapped capture. NEXT STEPS On MR 3678, David said this needs fixing at the QSG level and solving generically, and that quick hacks that only affect one specific thing won't help get there (https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3678#note_1671870). I agree the proper fix belongs in Qt: snap layer textures to device pixels, or offer a public shadow-only effect so the text never goes through a texture. I'd be glad to help test that. Once it exists, this workaround could be replaced, which I'd expect to be a fairly small change on the KDE side. I think this patch is a different kind of change from the rounding in MR 3678, though. It doesn't add any pixel-grid rounding in QML. It only stops drawing the visible text from a texture, so the text is drawn directly like any other label, and only the shadow goes through the effect. It is still a change to one component, and it relies on private GaussianBlur properties. With that in mind, would you consider it as a stopgap in libplasma? I'm happy to open an MR, or run more tests. -- You are receiving this mail because: You are watching all bug changes.
