Bug 504015 - Transparent horizontal lines in Kate, KWrite, etc. text editor components with 115% fractional scaling on Wayland
Summary: Transparent horizontal lines in Kate, KWrite, etc. text editor components wit...
Status: RESOLVED UPSTREAM
Alias: None
Product: frameworks-ktexteditor
Classification: Frameworks and Libraries
Component: general (other bugs)
Version First Reported In: 6.13.0
Platform: Fedora RPMs Linux
: NOR minor
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
: 505546 507111 (view as bug list)
Depends on:
Blocks:
 
Reported: 2025-05-10 14:40 UTC by Mohammad
Modified: 2025-08-30 18:55 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Transparent Horizontal Lines in Kwrite (288.25 KB, image/png)
2025-05-10 14:40 UTC, Mohammad
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mohammad 2025-05-10 14:40:26 UTC
Created attachment 181143 [details]
Transparent Horizontal Lines in Kwrite

SUMMARY


STEPS TO REPRODUCE
1. fractional scaling at 115%
2. open Kwrite

OBSERVED RESULT
 Horizontal transparent lines appear within the editor area.

EXPECTED RESULT
Normal KWrite Window

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux 6.14.5
KDE Plasma Version: KDE Plasma 6.3.5 wayland
KDE Frameworks Version: 6.13.0
Qt Version: 6.9.0
Comment 1 Christoph Cullmann 2025-05-11 08:09:23 UTC
Does that happen for some 125% scaling, too? Not sure if that will ever be fixed, with non 1/(2^x) scalings there will be always rounding errors.
Comment 2 Mohammad 2025-05-11 13:44:07 UTC
(In reply to Christoph Cullmann from comment #1)
> Does that happen for some 125% scaling, too? Not sure if that will ever be
> fixed, with non 1/(2^x) scalings there will be always rounding errors.

No it only appears with 115% scaling.
Comment 3 Christoph Cullmann 2025-05-11 14:19:01 UTC
Could we just not allow scaling that is not even representable as a proper floating point number? For X11 we only allow increments in 1/16 steps or something like that, 0.1 or 0.5 steps just lead to rounding issues everywhere, that is not fixable on the app level.
Comment 4 Nate Graham 2025-05-13 18:27:27 UTC
Not a KScreen bug; almost certainly something in KWrite or KTextEditor. If not that, *maybe* it's a KWin thing. CCing some KWin devs for more info.
Comment 5 Christoph Cullmann 2025-05-13 19:12:45 UTC
I only know that with strange scaling factors you might end up with rounding issues. If someone has time to search that in our code, that is welcome, I will not do that. I would recommend to use a better scaling factor as workaround, like the mentioned 1.25 that seems to help.
Perhaps you can try one more close to 1.15, like 1.125, that might work, too.
Comment 6 Kat Pavlu 2025-06-11 13:41:42 UTC
(In reply to Christoph Cullmann from comment #5)
> I only know that with strange scaling factors you might end up with rounding
> issues. If someone has time to search that in our code, that is welcome, I
> will not do that. I would recommend to use a better scaling factor as
> workaround, like the mentioned 1.25 that seems to help.
> Perhaps you can try one more close to 1.15, like 1.125, that might work, too.

I hit this issue today and tried different scaling factors.
It only happens with 1.15 scale. Not 1.00, not 1.05, not 1.10, not 1.20, not 1.25, not 1.125.
The lines always stay at the same horizontal place, they do not move when scrolling.
Comment 7 Kat Pavlu 2025-06-11 14:34:00 UTC
Also happens in kDevelop and Kile. So think it's the text editor component they all share.
Comment 8 Waqar Ahmed 2025-06-13 06:05:35 UTC
*** Bug 505546 has been marked as a duplicate of this bug. ***
Comment 9 John Kizer 2025-06-22 17:14:40 UTC
I can reproduce this on an EndeavourOS VM with Plasma 6.4.0, Kate 25.04.2.
Comment 10 Kat Pavlu 2025-06-22 17:24:06 UTC
I can still reproduce this on fedora 42. Plasma 6.4.
Comment 11 Waqar Ahmed 2025-07-16 12:43:21 UTC
*** Bug 507111 has been marked as a duplicate of this bug. ***
Comment 12 Waqar Ahmed 2025-08-30 18:18:25 UTC
There is nothing we can do here, I tried to debug this in icon border code, but everything is as expected. Feel free to report this to Qt etc.
Comment 13 Christoph Cullmann 2025-08-30 18:55:17 UTC
I still think that all stuff that is not some sane floating point number will lead to random rounding issues after some additions/multiplications :) But I got ignored in the past and only on X11 we tried to enforce sane zooming step in 1/16 or similar 1/2^x steps.