Created attachment 110651 [details] screenshot I use plasma 5.12.1 and kate 17.12.2 on Arch Linux, my display scale is 1.2 under X11. Every time I open kate I see horizontal lines (screenshot), they disappear when I resize or minimize/retore the window. This problem does not occur when I use default display scale.
My font settings are size 16, bold.
Should be fixed if I get https://bugreports.qt.io/browse/QTBUG-66036 fixed
Should hopefully be fixed with Qt 5.12, but we will keep this open until verified.
Apparently the similar bug in Konsole (Bug 399291) was not fixed with that Qt change. :(
*** Bug 402502 has been marked as a duplicate of this bug. ***
*** Bug 406172 has been marked as a duplicate of this bug. ***
*** Bug 399072 has been marked as a duplicate of this bug. ***
KDevelop is affected, too. Same behavior. (openSUSE 15.0 and openSUSE 15.1) This is with Nvidia Graphics. With some unknows reason the scale ratio is set to 1.1. then I see the horizontal lines. When set the scale factor to 1.0 the lines are not seen but all windows, strings, icons are LARGER, then smaller. If I go back to scale factor 1.1 the size of my desktop seems OK but the horizontal lines are back ... Because this behavior seems to be since 2016 ... How needs scaling? Which config files are affected? Whats the original values? Is there a documentation how it works?
*** Bug 411167 has been marked as a duplicate of this bug. ***
I can reproduce this on KDevelop, kate, and kwrite with: QT_SCALE_FACTOR=1.1 kwrite
I can reproduce this, too.
I play around with this some hours. The issue are rounding problems using QPainter in paintEvent. We loop over all lines, move each time the painter via translate(...) the line height down. Even though in logical coordinates that is e.g. 15 pixel on my machine here, it is internally some "evil" fraction that will lead to a 1 pixel skip after some lines :/ I did adjust the height here with some hack like // find a height that is ok for the current scale factor h = h * devicePixelRatioF(); h = int(h); h = h / devicePixelRatioF(); then it was already "ok", but a lot of other stuff breaks then ;=)
After more code inspection, I think we can improve here a bit, but not really fix that for 1.1. We need some non-fractional line height, both in "logic" and "real" coordinates. That means all is fine for stuff like 2x, 3x, ... But as soon as you start with 1.5, problems arise. We would try to improve for "nice" scalings like 0.5, 0.25, 0.125 by trying to adjust the font size until a value is reached that allows for both logic and real height to be a non-factional. That is easy for stuff like 1/2, 1/4, ... but likely infeasible for a number that is not even sanely representable as floating point (e.g. 1/10).
For those cases, could we just round up or down a bit? Vertical mis-alignment would be preferable to these ugly horizontal lines IMO.
Not really. The rounding errors add up, you will always end up with issues. Even the start position of the view is already then on some fraction of a pixel. I actually would more like that Qt would forbid "evil" scalings that are not at least the multiple of some 1/8 or 1/16.
Beside, please try the QT_SCALE_FACTOR=1.1 kwrite variant. For even the menu has maximal ugly repaint artifacts between the boundaries of the menu entries if I move over them (and they get selected) and I have random missing separators.
I have some potential fix, that works at least if you use scaling factors that are proper floating points like 1.25, 1.5, ... https://cgit.kde.org/ktexteditor.git/log/?h=hidpi-font-fixes Could somebody give this a try? I created an extra bug that we shall not per default propose such factory in our UI, Microsoft is more clever, they normally scale just in 25% steps, that is a proper factor. https://bugs.kde.org/show_bug.cgi?id=412447 Nate, could you perhaps take a look?
I merged my branch to master, more testers welcome. For me it fixed the artifacts for reasonable zoom factors.
That looks like a hack indeed. I always assumed the bounding box used for clearing/background rendering wasn't correctly rounded to whole pixels, see Konsole's attempt at bug 373232 comment 31. Top/Left need to be rounded down, while Bottom/Right need to be rounded up.
There is nothing to round in virtual pixel. e.g. if the font is 10 virtual pixel high, you get real 12.5 real pixel if you scale with 1.25. KTextEditor will not at all see this and we will get some ugly lines sprinkled in here and there. Even worse for scaling factors that never lead to full pixel ever again, like 0.1.
I looked again into the Qt bug https://bugreports.qt.io/browse/QTBUG-66036 I can avoid a lot of the artifacts by not using anti-aliasing. With anti-aliasing, even just filling 10 times a 14 pixel high rect each 14 pixel leads to artifacts :///
Git commit 165a7a3b526ca70635e36e036e2f9cdd4b5947ce by Christoph Cullmann. Committed on 01/10/2019 at 19:40. Pushed by cullmann into branch 'master'. avoid the font choosing magic and turn of anti aliasing this avoids most of the strange artifacts for me but not all.... see https://bugreports.qt.io/browse/QTBUG-66036 M +9 -70 src/render/katerenderer.cpp M +4 -1 src/view/kateviewinternal.cpp https://commits.kde.org/ktexteditor/165a7a3b526ca70635e36e036e2f9cdd4b5947ce
Git commit 2d6c8f17f5e040ac05ea43ba1726c13c38e806a3 by Christoph Cullmann. Committed on 01/10/2019 at 20:02. Pushed by cullmann into branch 'master'. next rendering artifact goes away if you adjust the clip rect a bit M +10 -1 src/view/kateviewinternal.cpp https://commits.kde.org/ktexteditor/2d6c8f17f5e040ac05ea43ba1726c13c38e806a3
For me this works now, even for strange factors like 1.1, at least in the text area, there are still other artifacts with that in the menus/... Qt stuff
That's what I meant, thanks!
I still want to get rid of factors like 1.1, as they still have lots of small glitches everywhere as you round the whole time, unlike for 1/16 or so. But at least with these hacks it not that bad. I added the hints to the matching konsole bug, there at least many artifacts already disappear without AA. (but not all)
And with stuff like 1.1 and some font sizes, you will still get sometimes a small artifact line ever xx lines. That's just the bad scaling of the rounding. But I think with that on can live. With some sane factor like 1.25 or 1.5 all is perfectly fine here now.
Git commit f239eea7057eb95716a671a04b59bb01411380fc by Christoph Cullmann. Committed on 03/10/2019 at 00:11. Pushed by cullmann into branch 'master'. QRectF instead of QRect solves clipping issues, even thought the rectangle has pure integer coordinates/sizes M +3 -4 src/view/kateviewinternal.cpp https://commits.kde.org/ktexteditor/f239eea7057eb95716a671a04b59bb01411380fc
I created bugs for the clipping issues found here and in Konsole. https://bugreports.qt.io/browse/QTBUG-78962 https://bugreports.qt.io/browse/QTBUG-78963
fillRect bug with anti-aliasing reported here https://bugreports.qt.io/browse/QTBUG-78964
Git commit 2b23256b0a47526715e98352fe3a12db520c306f by Nate Graham. Committed on 16/10/2019 at 14:50. Pushed by ngraham into branch 'master'. [KCM] Limit scale factor increment to 6.25% on X11 Summary: Because of the nature of floating point math and various Qt and X11 bugs, limiting the scale factor increment to 0.0625 (6.25% in percentage form) will improve the display in many apps. For more information, see the discussions in https://bugreports.qt.io/browse/QTBUG-66036 and the following bug reports: Related: bug 412447, bug 373232 Depends on D24370 Depends on D24371 Test Plan: {F7500922} Reviewers: #plasma, romangg, mart Reviewed By: #plasma, romangg, mart Subscribers: cullmann, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D24373 M +9 -4 kcm/package/contents/ui/Panel.qml M +2 -2 kded/output.cpp https://commits.kde.org/kscreen/2b23256b0a47526715e98352fe3a12db520c306f