Bug 373232

Another way to reproduce this is to fill up the screen with text with the mouse outside the window area, then move the mouse over the window area. As soon as the mouse crosses over, lines will often appear. Scrolling clears the lines. Moving the mouse back over the window area causes them to reappear. 

The seems to related to redraw/refresh.

I am also affected by this. 
Debian Testing (Stretch),
Plasma 5.8.2
Turning on scale factor makes random horizontal lines appear in Konsole, on both screens (one is hidpi, the other is a regular screen).
Resizing Konsole windows makes these lines appear and disappear.

Arch upgrade Konsole to Version 16.12.0
This issue has been resolved.

Sorry, the problem still exists. It seems to takes longer to make the lines show up now.

I built konsole from the current git master (v16.12.0-23-gb7e75cf) on Ubuntu 16.10 with most KDE packages from ppa:kubuntu-ppa/backports, and I see vertical glyph cutoff/offsetting and partially also horizontal lines.

Depending on the text-cursor position (e.g., in vim), glyphs in a complete text line in Konsole are cut off vertically. These characters need not be fancy Unicode ones, plain ASCII suffices.  The effect vanishes when the terminal is redrawn, e.g., after switching Desktops back and forth.  Displays -> Scale -> Scale Factor is 1.4 here (2560x1440px).

Created attachment 103366 [details]
Screenshot showing the effect in vim in line 54+55

How I created the screenshot: Create text file with sufficient number of lines; open with vim; move cursor down until I'm at the terminal's last line and beyond; move back up until cursor is about in the vertical middle of the terminal.

Note: I already saw this bug with konsole 4:16.04.3-0ubuntu1 on Ubuntu 16.10, which is why I tried konsole's git HEAD in the first place.

confirming on Chromebook Pixel 2013. Freshly repaved. KDE Neon stable user edition (Plasma 5.8.5, Framework 5.29.0, Qt 5.7.0, kernel 4.4.0-59-generic, konsole 16.12.1)

This did not occur on Kubuntu 16.04 (the previous OS on the same machine).

Created attachment 103452 [details]
after highlighting some text in the terminal

the line sometimes shows the backdrop image.

*** Bug 376039 has been marked as a duplicate of this bug. ***

On version 16.12.1, using Intel drivers with Xorg's modesetting, and glamor 2D acceleration, this behaviour doesn't appear anymore.

I too also have this issue (on Arch linux, using my Dell XPS 15 laptop).  Don't really need to do anything special to reproduce the issue other than use konsole for a bit, and routinely the clear horizontal lines will come by (usually on the line below the current terminal).

Yes It is clear the scaling causes these issues - even the non blicking square cursor looks off.

I'm not entirely sure what that scaling does or how to detect it in Konsole (which does a lot of calculations).

I've found that setting XServer DPI manually fixes these fractional scaling problems.
On my 2560x1440 display I use a DPI of 144 (i.e. a scaling factor of 1.5x), which caused problems in regular Qt programs, the lockscreen, shutdown/logout/suspend dialog, Okular etc.

To fix this, added "-dpi 144" to ServerArguments in my sddm.conf and set display scaling back to 1.0x.
This makes KDE and all Qt programs scale flawlessly but GTK programs (i.e. Firefox) remain unscaled which is an acceptable tradeoff for me.

I apologize if I'm spamming the mailing lists as I've been reposting this on all of the bugs I've been tracking related to this issue.

setting font to a fixed DPI made horizontal lines disappear on konsole for me

see http://www.lorenzobettini.it/2016/07/hidpi-in-kde-plasma/

*** Bug 381646 has been marked as a duplicate of this bug. ***

(In reply to Lluís from comment #15)
> setting font to a fixed DPI made horizontal lines disappear on konsole for me
> 
> see http://www.lorenzobettini.it/2016/07/hidpi-in-kde-plasma/

Hi, what is the situation when you set the Scale Factor (Displays -> Scale -> Scale Factor) to a fractional value like 1.6 or 1.5?

I found that these lines are actually transparent to the background (the window behind Konsole).

(In reply to CnZhx from comment #17)
> Hi, what is the situation when you set the Scale Factor (Displays -> Scale -> Scale Factor) to a fractional value like 1.6 or 1.5?

this is what I have (1.4)

Hi all , 
I don't think this is related to konsole only. 
I am getting the same glitch in kate , just use a dark background and it will be easily visible

(In reply to Lluís from comment #19)
> (In reply to CnZhx from comment #17)
> > Hi, what is the situation when you set the Scale Factor (Displays -> Scale -> Scale Factor) to a fractional value like 1.6 or 1.5?
> 
> this is what I have (1.4)

I havn't tried the Scale Factor for a long time. I tried it today with openSUSE Tumbleweed snapshot 20170810. In current environment, with a scaling factor of 1.5, the white horizontal line in Konsole appears very occasionally. It is much less annoying than before. Thanks :)

I am facing the same problems since a few days. It worked before like a charm.
I am using the resolution of 3840*2160 and changed the scaling factor to 1.4 since it's a pretty big screen.

I am also using the intel modesetting driver which accelerated via glamor.

Since these vertical lines started to appear my kontact/kmail is also broken. It duplicated the toolbar and also the mouse cursor seems to be offset from it's visible position and where it actually is. This means it's nearly impossible to point at something.

The only thing that fixes is changing the scaling factor back to 1.0 but then everything is too small to read and very tiresome for the eyes. I'd really appreciate any more insight. I even updated from qt 5.7 to 5.9 but the problem persists.

Just another me too. Qt 5.7.1, Plasma 5.10.4, Konsole 17.04.3. 3840x2160, scaling factor 1.5. Happens with amdgpu and nvidia-drivers.

I have the same problem (lines in Konsole and Kate) with KDE neon on a XPS 13 and I can confirm that a workaround is to create a sddm.conf (with sddm --example-config > /etc/sddm.conf) and add "-dpi 144" to ServerArguments. Then set Scale to 1 in System Settings and reboot.

*** Bug 385928 has been marked as a duplicate of this bug. ***

*** Bug 388539 has been marked as a duplicate of this bug. ***

I am affected by this in Arch Linux on a Lenovo laptop. However, I have seen it in a desktop system too (with Arch). Current scaling factor is 1.3. Applications affected include Kate and Konsole.

Created attachment 109683 [details]
Horizontal Lines in Kate on Arch Linux

These appear without doing anything out of the ordinary.

Hi, notwithstanding the bug the best solution is indeed to set the Scale Factor to 1 and then experiment with the Font Resolution. For me it worked perfectly with forcing 125 DPI. Dont forget to enable anti-alising about the force DPI setting. 
NO lines or fragments anywhere and the whole display is crystal clear all over.

(In reply to aerioeus from comment #29)
> Hi, notwithstanding the bug the best solution is indeed to set the Scale
> Factor to 1 and then experiment with the Font Resolution. For me it worked
> perfectly with forcing 125 DPI. Dont forget to enable anti-alising about the
> force DPI setting. 
> NO lines or fragments anywhere and the whole display is crystal clear all
> over.

Font scaling is a workaround but it is not enough. Display scaling also affects UI elements scaling, such as buttons, tabs and icons. Without it, for example, Yakuake tabs and window footer are too small for the scaled fonts.

There's a patch undergoing review that aims to work around this issue: https://phabricator.kde.org/D10232

+1

Afaics the patch is only for Konsole.
All other applications (Kate, Kdevelop, Okular?, ...) won't be fixed by that patch.

Kate and KDevelop were already fixed upstream in Qt 5.12: https://bugreports.qt.io/browse/QTBUG-66036

It's also possible that this bug also will be improved or fixed by that patch.

*** Bug 396457 has been marked as a duplicate of this bug. ***

I'm no longer able to reproduce this with Konsole from git master as of https://cgit.kde.org/konsole.git/commit/?id=9836d430253f40054371440a45ceed578adba5fc

Can anyone confirm that they're still seeing the issue with Konsole from current git master?

I haven't seen this issue for quite a while now, using Konsole 17.12.3-1ubuntu1.  Seems to have been fixed in or before the release I'm currently using.

I'm receiving multiple reports of the issue not being reproducible anymore. Calling this fixed, then!

I can still reproduce it in Konsole and Kate, the same as before.

4.17.6-1-ARCH #1 SMP PREEMPT Wed Jul 11 19:14:29 UTC 2018 x86_64 GNU/Linux
Lenovo ThinkPad
Scale Factor: 1.3

The steps to reproduce are the same as the first comment above.

adding this info to my prior comment.
kate 18.04.3
plasmashell 5.13.3

At a display scaling of 1.3, the current appearance remains the same as in the attachments already added to this report. The problem is not present at display scaling of 1.0.

My apologies for a 3rd comment. However, I forgot to add this important info:
konsole 18.04.3

We need a test with Konsole from git master, not 18.04.3

I can still reproduce this issue in master.

Darn, thanks for testing.

Created attachment 114169 [details]
Still repo on KDE Neon 5.13.3

With KDE neon 15.3, the issue has gotten harder to reproduce. But horizontal lines still show up with fractional scaling, especially when the mouse is used to highlight text and scroll.

I can reproduce this as well using scaling of 1.7. Tested on Arch-Linux with linux-4.17.11, plasma-5.13.3, qt-5.11.1 and kdeframeworks-5.48.0. A temporary workaround for me: Set scaling to 2x, but force DPI of 154 in Font-Settings.

It seems only fixed for 1.5, other scalings e.g. 1.3 does still have the random lines.

(In reply to Bo Simonsen from comment #47)
> It seems only fixed for 1.5, other scalings e.g. 1.3 does still have the
> random lines.

Yes, reproducible here with 1.3.

i am already couting days to the 2 year anniversary bug-report ;)

This is still happening for me with scale factor 1.5

KDE: 5.13.4
Konsole: 18.04.3
Fedora 28

I can confirm this bug is still present as well. 

Gentoo using 4.18.6 kernel
Konsole 18.04.3
Desktop is at 4k

Still happening on Kubuntu 18.04 with fractional scale factors

I'm seeing it with Konsole 18.08.01 on Arch Linux. Is there a similar bug report open for Kate? Kate has these horizontal lines too.

Kate was fixed upstream in Qt 5.12: https://bugreports.qt.io/browse/QTBUG-66036

It's quite likely that this will be as well. In fact, so likely, that I'm going to mark this as RESOLVED UPSTREAM.

Once Qt 5.12 comes out, we can re-open this if the lines are still present. Thanks everyone!

(In reply to bugreporter11 from comment #53)
> Is there a similar bug
> report open for Kate? Kate has these horizontal lines too.

bug 390451

> Once Qt 5.12 comes out, we can re-open this if the lines are still present.
> It's quite likely that this will be as well.

Could we let this report open, until we know for sure instead of closing it without a single confirmation that it has been really fixed.

There's not much difference, really. This bug is on my list of bugs to monitor, and once Qt 5.12 is released, undoubtedly folks who are affected will chime in. So there's no danger of it getting missed, don't worry. :)

*** Bug 399072 has been marked as a duplicate of this bug. ***

*** Bug 350651 has been marked as a duplicate of this bug. ***

I use display scale 1.2, Qt 5.12 beta2 on Arch Linux.
Horizontal lines persist on kate and konsole.
Is rebuild the packages against Qt 5.12 required to solve the bug?

NooOooOOOOooooooooooo... :(

Is fractional scaling at all supported by Qt?

At least the documentation still states:

http://doc.qt.io/qt-5/highdpi.html
Note: Non-integer scale factors may cause significant scaling/painting artifacts.

That's correct, there is no *official* support. However KScreen allows you to set a fractional scale factor on X11, and quite a few people do so for what I consider to be legitimate reasons (e.g some 4k screens are 13 inches, others are 27 inches).

I can confirm that on latest 5.12 beta this issue still appears for me in both Kate and Yakuake.

Kubuntu 18.04.1 - Konsole Version 17.12.3 - bug still exists
(gnome-terminal works just fine)

Same issue.

kde-frameworks: 5.50.0
Konsole, kate: 18.04.3
Qt: 5.11.1
Scale factor: 1.5
Font dpi: 144

Same on KDE neon 18.04 (git-stable)

Plasma: 5.14.4
Frameworks: 5.54.0
Applications: 18.12.0
Qt: 5.11.2

Linux: 4.19.8 (installed via ukuu)

Qt 5.12
Konsole 18.12.0

The issue still exists

Issue still there in Konsole, Yakuake,Kate
Plasma version 5.14.4
Scaling at 1.4
Linux 4.19

There is no need to state it multiple times. If the issue gets fixed, the bug gets closed.

> There is no need to state it multiple times. 
> If the issue gets fixed, the bug gets closed.

I guess the reason why there are so many "me too"s is that there is nothing done about it and the bug was filed exactly two years ago. 
This is rather basic functionality broken in a (these days) rather common environment.

I could now go on and complain about bugs in core-functionality, while developer time is spent on KDE-branded applications just for the sake of having a QT-clone available, but I guess it would do no good.

(In reply to Christoph Feck from comment #70)
> There is no need to state it multiple times. If the issue gets fixed, the
> bug gets closed.

The main reason to state it again is that it was closed as `Fixed in Qt5.12`, yet after update to 5.12 it is not. Hence the new "me too" posts .

(In reply to 4k1r4.rulez from comment #72)
> The main reason to state it again is that it was closed as `Fixed in
> Qt5.12`, yet after update to 5.12 it is not. Hence the new "me too" posts .
And then it was re-opened, which is its current status. So there is no need to say, "This is still a problem in version X.Y!" because the current open status already communicates that information.

With Applications/18.12 commit 807ac77061604c2ac7cf84b0a0b29dd949a6c634 makes it even worse, for e.g. "mc". Not sure if it should be a seperate bug report?

(In reply to Bo Simonsen from comment #74)
> With Applications/18.12 commit 807ac77061604c2ac7cf84b0a0b29dd949a6c634
> makes it even worse, for e.g. "mc". Not sure if it should be a seperate bug
> report?

That's probably bug#402415 (unrelated to HiDPI scaling though).

*** Bug 403251 has been marked as a duplicate of this bug. ***

*** Bug 403911 has been marked as a duplicate of this bug. ***

In case somebody are working on a solution I thought I may add my observations (has been trying my self to solve it but without luck so far).

1. The lines are actually holes in the painter image/canvas. You may see that by having a window with a curtain color and put that behind the Konsole, you may see the "lines" in Konsole have the same colors.
2. Using scaling 1.5, the bug is not reproducible if you only allow even font sizes, i.e.
  
    _fontHeight = _fontHeight % 2 ? _fontHeight + 1 : _fontHeight;

after setting _fontHeight in TerminalDisplay::fontChange(const QFont&). This implies pretty much that the size calculations with respect to _fontHeight divisions may not be accurate.
3. I really do not think this bug has anything to do with QT, which makes sense since konsole is still "broken" with QT 5.12.

Can anybody verify the lines go away if konsole is started with --notransparency?

(In reply to Bo Simonsen from comment #79)
> Can anybody verify the lines go away if konsole is started with
> --notransparency?

Yes, I can no longer reproduce any unwanted horizontal lines if Konsole is started with --notransparency

But that also eliminates any form of blur or transparency of course. :)

Yes, confirmed that with '--notransparency' the artifacts are gone.

(In reply to Harry ten Berge from comment #81)
> Yes, confirmed that with '--notransparency' the artifacts are gone.

Assume it is a QT bug after all.

I can also confirm that the lines are gone when Konsole is started with the '--notransparency' flag. I wasn't able to reproduce/test this with kate because that flag doesn't exist.

Created attachment 120364 [details]
Konsole with Midnight Commander garbled

In my case, --notransparency helps with raw console output, but running e.g. Midnight Commander shows somewhat garbled output with some rows and columns around characters undrawn. See the attached screenshot, it is with scaling factor 1.7.

Created attachment 120365 [details]
Konsole with Midnight Commander correct

For reference, this is how it should look.

Which Konsole version is comment #85? I thought we fixed line graphics already.

This is on Kubuntu 19.04.
Konsole: 18.12.3
KDE Plasma: 5.15.4
KDE Frameworks: 5.56.0
Qt: 5.12.2

Please test Konsole 19.04, see bug 402415. I am unsure if anyone tested line graphics using fractional scaling.

Can reproduce using Konsole 19.04 as well as from git master.

Looks like that issue is tracked by Bug 406770.

(In reply to Harry ten Berge from comment #81)
> Yes, confirmed that with '--notransparency' the artifacts are gone.

I can confirm it is most certainly not. They are a lot less, but not gone. still depends on font size, font type, but it can still occur.

This is on konsole 19.04.1 (KDE Neon 18.04)

Could it be that the bug is masked with --notransparency by the black window background?

(In reply to Nate Graham from comment #90)
> Looks like that issue is tracked by Bug 406770.

Note that on my screenshot vertical and horizontal dashes are garbled. I don't see that in Bug 406770.

Created attachment 120456 [details]
konsole_photo_prompt_return

Created attachment 120457 [details]
konsole_ls

In current and above screenshot, you can see I'm using a black background. I've had to take a photograph, as pressing the screenshot buttons actually removes the visual artifact from konsole.

I think I may have tracked it down a little bit in the source code:

In TerminalDisplay.cpp of Konsole it says
> 674: painter.fillRect(rect, color);
> 678: painter.fillRect(rect, backgroundColor);

If you comment out both, no background is drawn, but I also don't see any more horizontal or vertical lines (the latter in mc). 

When I set the first rect fixed to (0,0,100,20) for example and made a selection of the content or scrolled up and down to provoke those lines, the horizontal line was only drawn over the painted rect.

Maby that's a starting point for further investigations. ;-)


## System

Operating System: Manjaro Linux 
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.58.0
Qt Version: 5.12.3
Kernel Version: 5.1.4-1-MANJARO
Konsole: Master (926bc5715448bf62ad6060e64aef7c5c5e1d51f0)

(In reply to Lastique from comment #92)
> Note that on my screenshot vertical and horizontal dashes are garbled. I
> don't see that in Bug 406770.
What you are seeing is bug#402415 that should be fixed in konsole 19.04.0, but you are using 18.12.3 that still has this problem.

Created attachment 120461 [details]
Konsole Select Text

There's no need to launch Midnight Commander, just selecting multiple lines will suffice.

(In reply to Wolfgang Bauer from comment #96)
> What you are seeing is bug#402415 that should be fixed in konsole 19.04.0,
> but you are using 18.12.3 that still has this problem.

I still have this problem with Konsole 19.04.1, scaling set to 1.2.

(In reply to Fabian Lesniak from comment #98)
> (In reply to Wolfgang Bauer from comment #96)
> > What you are seeing is bug#402415 that should be fixed in konsole 19.04.0,
> > but you are using 18.12.3 that still has this problem.
> 
> I still have this problem with Konsole 19.04.1, scaling set to 1.2.

Which problem exactly?
I was talking specifically about the "ugly" (horizontal and vertical) line drawing characters in the picture of comment#84, that should be fixed in 19.04.

Created attachment 120493 [details]
Konsole 19.04.1 ugly lines

(In reply to Wolfgang Bauer from comment #99)
> Which problem exactly?
> I was talking specifically about the "ugly" (horizontal and vertical) line
> drawing characters in the picture of comment#84, that should be fixed in
> 19.04.

How have you tested this? The ugly horizontal and vertical lines are simply not fixed. Even with 19.04. See screenshot. Scaling is set to 1.7.

Operating System: KDE neon 5.15
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.58.0
Qt Version: 5.12.0
Kernel Version: 4.18.0-20-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 15,6 GiB

(In reply to Nicolas from comment #100)
> Created attachment 120493 [details]
> Konsole 19.04.1 ugly lines
> 
> (In reply to Wolfgang Bauer from comment #99)
> > Which problem exactly?
> > I was talking specifically about the "ugly" (horizontal and vertical) line
> > drawing characters in the picture of comment#84, that should be fixed in
> > 19.04.
> 
> How have you tested this? The ugly horizontal and vertical lines are simply
> not fixed. Even with 19.04. See screenshot. Scaling is set to 1.7.

Please take a look at the screen shot in comment#84. The lines themselves are "corrupted", and that should be fixed in 19.04.

On your screenshot the *background* shows artifacts, I never said that this is fixed.

(In reply to Wolfgang Bauer from comment #101)
> On your screenshot the *background* shows artifacts, I never said that this
> is fixed.
There's also bug#406770 btw, as already mentioned here.

Created attachment 120495 [details]
Horizontal lines in Vim; Fractional Scaling 1.5; Transparency=True

Theses lines appear while scrolling in Vim.

* Interestingly their distance is mostly 5 rows, but it varies rarely.
* Those lines do not appear or disappear in vim while scrolling IF the pointer is on the top or on the bottom.
* Those are the same horizontal lines which can be observed in Konsole outside of Vim, which can be seen in the next screenshot.


# System 

Plasmashell 5.15.5 
Konsole 19.04.1
Fractional Scaling 1.5

Created attachment 120496 [details]
Horizontal lines in Konsole; Fractional Scaling 1.5; Transparency=True

While not ideal, I've managed to work around this by launching Konsole without DPI scaling and then reexporting the environment variable for applications launched from within the shell. This gets rid of the horizontal line artifacts without interfering with other applications. 

To do this I changed konsole.desktop's `Exec` line from `konsole` to `_QT_SCREEN_SCALE_FACTORS="$QT_SCREEN_SCALE_FACTORS" QT_SCREEN_SCALE_FACTORS="" konsole` and I've added the following to my shell config:

    # fish
    set -xg QT_SCREEN_SCALE_FACTORS $_QT_SCREEN_SCALE_FACTORS
    # bash
    export QT_SCREEN_SCALE_FACTORS=$_QT_SCREEN_SCALE_FACTORS

(In reply to Robbert van der Helm from comment #105)
> While not ideal, I've managed to work around this by launching Konsole
> without DPI scaling and then reexporting the environment variable for
> applications launched from within the shell. This gets rid of the horizontal
> line artifacts without interfering with other applications. 
> 
> To do this I changed konsole.desktop's `Exec` line from `konsole` to
> `_QT_SCREEN_SCALE_FACTORS="$QT_SCREEN_SCALE_FACTORS"
> QT_SCREEN_SCALE_FACTORS="" konsole` and I've added the following to my shell
> config:
> 
>     # fish
>     set -xg QT_SCREEN_SCALE_FACTORS $_QT_SCREEN_SCALE_FACTORS
>     # bash
>     export QT_SCREEN_SCALE_FACTORS=$_QT_SCREEN_SCALE_FACTORS

I can confirm that this work around works for me as well! Thanks! :-)

Adjusting line spacing to 1px resolves lines for me. 
(Konsole Profile > Appearance > Misc)

Display Scaling = 1.3
Operating System: KDE neon 5.16
KDE Plasma Version: 5.16.2
KDE Frameworks Version: 5.59.0
Qt Version: 5.12.3

(In reply to genbushi from comment #107)
> Adjusting line spacing to 1px resolves lines for me. 
> (Konsole Profile > Appearance > Misc)
> 
> Display Scaling = 1.3
> Operating System: KDE neon 5.16
> KDE Plasma Version: 5.16.2
> KDE Frameworks Version: 5.59.0
> Qt Version: 5.12.3

It is better than before, but it doesn't resolve it for me

Has this issue been reported upstream? It was believed that this was caused by 
https://bugreports.qt.io/browse/QTBUG-66036

But that issue is closed and did not help here. Could a KDE dev open up a new issue for this on their bugtracker?

(In reply to Robbert van der Helm from comment #105)
> While not ideal, I've managed to work around this by launching Konsole
> without DPI scaling and then reexporting the environment variable for
> applications launched from within the shell. This gets rid of the horizontal
> line artifacts without interfering with other applications. 
> 
> To do this I changed konsole.desktop's `Exec` line from `konsole` to
> `_QT_SCREEN_SCALE_FACTORS="$QT_SCREEN_SCALE_FACTORS"
> QT_SCREEN_SCALE_FACTORS="" konsole` and I've added the following to my shell
> config:
> 
>     # fish
>     set -xg QT_SCREEN_SCALE_FACTORS $_QT_SCREEN_SCALE_FACTORS
>     # bash
>     export QT_SCREEN_SCALE_FACTORS=$_QT_SCREEN_SCALE_FACTORS

This works !!

See https://bugreports.qt.io/browse/QTBUG-66036 and https://bugs.kde.org/show_bug.cgi?id=390451

For me most things already work if we do just remove

paint.setRenderHint(QPainter::Antialiasing, _antialiasText);

Then at least many artifacts are gone here for several QT_SCREEN_SCALE=1.3 and co ratios.

I think the remaining ones need some clip rect + 1 hack like in the above bug of KTextEditor...

This small change fixes 99% of the artifacts for me:

diff --git a/src/TerminalDisplay.cpp b/src/TerminalDisplay.cpp
index 5753ae74..fabf5907 100644
--- a/src/TerminalDisplay.cpp
+++ b/src/TerminalDisplay.cpp
@@ -1289,7 +1289,9 @@ void TerminalDisplay::paintEvent(QPaintEvent* pe)
         drawBackground(paint, rect, getBackgroundColor(), true /* use opacity setting */);
     }
 
-    paint.setRenderHint(QPainter::Antialiasing, _antialiasText);
+    // only turn on text anti-aliasing, never turn on normal antialiasing
+    // set https://bugreports.qt.io/browse/QTBUG-66036
+    paint.setRenderHint(QPainter::TextAntialiasing, _antialiasText);
 
     foreach(const QRect & rect, dirtyImageRegion) {
         drawContents(paint, rect);

I will apply that in master, please test this.

Git commit 2c10032170ac9c01b71bd4d405c2d7ba40786c68 by Christoph Cullmann.
Committed on 02/10/2019 at 20:54.
Pushed by cullmann into branch 'master'.

fix many of the rendering artifacts for hi-dpi setups

please test by setting some scale factor of e.g. 1.5 or 1.0625

for me most artifacts are now gone

still very buggy for e.g. scaling of 1.1, but we have other patches for
that

M  +3    -1    src/TerminalDisplay.cpp

https://invent.kde.org/kde/konsole/commit/2c10032170ac9c01b71bd4d405c2d7ba40786c68

Git commit 2c10032170ac9c01b71bd4d405c2d7ba40786c68 by Christoph Cullmann.
Committed on 02/10/2019 at 20:54.
Pushed by scmsync into branch 'master'.

fix many of the rendering artifacts for hi-dpi setups

please test by setting some scale factor of e.g. 1.5 or 1.0625

for me most artifacts are now gone

still very buggy for e.g. scaling of 1.1, but we have other patches for
that

M  +3    -1    src/TerminalDisplay.cpp

https://commits.kde.org/konsole/2c10032170ac9c01b71bd4d405c2d7ba40786c68

Created attachment 122981 [details]
pre patch with QT_SCALE_FACTOR=1.5

Created attachment 122982 [details]
post patch with QT_SCALE_FACTOR=1.5

*** Bug 406770 has been marked as a duplicate of this bug. ***

For me the other artifacts disappear if I alter:

void TerminalDisplay::processFilters()

to always do a full update instead of 

update(preUpdateHotSpots | postUpdateHotSpots);

=> this means here we have some small rounding issue...

Perhaps that was the wrong update(), even if one tweaks that to be a bit more lax, the ranges are not that right. A better candidate is the update(dirtyRegion)

Modifying what it is done here:

 // if the characters on the line are different in the old and the new _image
        // then this line must be repainted.
        if (updateLine) {
            dirtyLineCount++;

            printf ("update line %d %d\n", tLy, y);

            // add the area occupied by this line to the region which needs to be
            // repainted
            QRect dirtyRect = QRect(_contentRect.left() + tLx -1,
                                    _contentRect.top() + tLy + _fontHeight * y -1,
                                    _fontWidth * columnsToUpdate +2,
                                    _fontHeight+2);

            qDebug() << "dirty line" << dirtyRect;

            dirtyRegion |= dirtyRect;
        }

has direct effect on the remaining artifacts, thought my tries to just pad the stuff a bit just lead to different white artifacts, which is strange ;)

Git commit b025e4234c8e0d15cf33a392ba3f71c802fc1b2c by Christoph Cullmann.
Committed on 02/10/2019 at 22:43.
Pushed by cullmann into branch 'master'.

anti-alias line character painting, too, with the text aliasing config options

M  +8    -0    src/TerminalDisplay.cpp

https://invent.kde.org/kde/konsole/commit/b025e4234c8e0d15cf33a392ba3f71c802fc1b2c

Git commit b025e4234c8e0d15cf33a392ba3f71c802fc1b2c by Christoph Cullmann.
Committed on 02/10/2019 at 22:43.
Pushed by scmsync into branch 'master'.

anti-alias line character painting, too, with the text aliasing config options

M  +8    -0    src/TerminalDisplay.cpp

https://commits.kde.org/konsole/b025e4234c8e0d15cf33a392ba3f71c802fc1b2c

Unfortunately for the remaining artifacts the only local hack I have is to do

    // update the parts of the display which have changed
    update();

instead of

    // update the parts of the display which have changed
    update(dirtyRegion);

which is for sure no good idea.

Whatever I do, at the moment I get always artifacts somewhere at the borders of the region that is painted :/

I created bugs for the clipping issues found here and in KTextEditor

https://bugreports.qt.io/browse/QTBUG-78962

https://bugreports.qt.io/browse/QTBUG-78963

If I am not wrong, see no way how Konsole could easily work around the paintEvent clipping issue beside doing full update() calls for the case that the devicePixelRatio is no pure integer value.

Would that be an acceptable workaround for the moment?

fillRect bug with anti-aliasing reported here 

https://bugreports.qt.io/browse/QTBUG-78964

I have no solution for the clipping issue, but I reported that up-stream to Qt.
The update() without region solution might be possible, but seems costly.

I would like to backport my two commits turning on/off aliasing at the right locations. That already fixed "most" of the rendering issues for me here with 1.5 scaling.

Would that be OK?

Git commit a3bc2f9667696a37b291852a2df851433cc4377b by Christoph Cullmann.
Committed on 03/10/2019 at 19:44.
Pushed by cullmann into branch 'Applications/19.08'.

fix many of the rendering artifacts for hi-dpi setups

please test by setting some scale factor of e.g. 1.5 or 1.0625

for me most artifacts are now gone

still very buggy for e.g. scaling of 1.1, but we have other patches for
that

M  +3    -1    src/TerminalDisplay.cpp

https://invent.kde.org/kde/konsole/commit/a3bc2f9667696a37b291852a2df851433cc4377b

Git commit 36cd1aa267cf616d8135e38f4da7e4142f64059a by Christoph Cullmann.
Committed on 03/10/2019 at 19:44.
Pushed by cullmann into branch 'Applications/19.08'.

anti-alias line character painting, too, with the text aliasing config options

M  +8    -0    src/TerminalDisplay.cpp

https://invent.kde.org/kde/konsole/commit/36cd1aa267cf616d8135e38f4da7e4142f64059a

Git commit 36cd1aa267cf616d8135e38f4da7e4142f64059a by Christoph Cullmann.
Committed on 03/10/2019 at 19:44.
Pushed by scmsync into branch 'Applications/19.08'.

anti-alias line character painting, too, with the text aliasing config options

M  +8    -0    src/TerminalDisplay.cpp

https://commits.kde.org/konsole/36cd1aa267cf616d8135e38f4da7e4142f64059a

Ok, I think the easy stuff we can workaround is done.

Now we either need to wait for

https://bugreports.qt.io/browse/QTBUG-78963

to be resolved (or shown that I was wrong and it is something different) or we need to think about doing more full update() calls for the fractional scaled case...

This is probably off-topic, but did anyone try setting the "Global scale" to 1 and increasing only the DPI to say 160 or 192 (2x96) in the fonts kcm? I did that (DPI 192) then increased the size of the icons, and both Qt and GTK3+ apps seem to increase the sizes of almost all the UI elements to accommodate the bigger text and they look fine. I saw the pictures in Christoph Culmann's blog post: https://cullmann.io/posts/kde-qt-highdpi-scaling/ and the UI on my setup looks very similar (I just don't have a place to upload a huge jpg/png file).

The only piece of UI that doesn't seems to scale up when I increase the DPI / font size are checkboxes, which is something I can live with.

If you do that, in most cases, the same scaling mechanisms will kick in, see https://doc.qt.io/qt-5/highdpi.html

"The application attribute Qt::AA_EnableHighDpiScaling, introduced in Qt 5.6, enables automatic scaling based on the pixel density of the monitor."

Most applications set that, to behave the way you describe, but that will result in exactly the same problems as if you set some "x.x" scale factor manually.

For me just using the "I want to have 1.5" config does work easier.

=> But I must confess, Konsole is missing that flag, which it should have set to behave well for desktop envs that just tweak the DPI.

Git commit 95eb7c98118244c235bcca5a0b9ff73cd08c1816 by Christoph Cullmann.
Committed on 03/10/2019 at 21:39.
Pushed by cullmann into branch 'master'.

enable hidpi auto scaling

M  +4    -3    src/main.cpp

https://invent.kde.org/kde/konsole/commit/95eb7c98118244c235bcca5a0b9ff73cd08c1816

Git commit 95eb7c98118244c235bcca5a0b9ff73cd08c1816 by Christoph Cullmann.
Committed on 03/10/2019 at 21:39.
Pushed by scmsync into branch 'master'.

enable hidpi auto scaling

M  +4    -3    src/main.cpp

https://commits.kde.org/konsole/95eb7c98118244c235bcca5a0b9ff73cd08c1816

Hmpf, most of our applications still miss that flag and look strange in non-plasma desktop settings :/

Git commit 54820e0ff2745add8b8353f538ad67d66b657d49 by Christoph Cullmann.
Committed on 04/10/2019 at 18:26.
Pushed by cullmann into branch 'Applications/19.08'.

enable hidpi auto scaling

M  +4    -3    src/main.cpp

https://invent.kde.org/kde/konsole/commit/54820e0ff2745add8b8353f538ad67d66b657d49

Git commit 54820e0ff2745add8b8353f538ad67d66b657d49 by Christoph Cullmann.
Committed on 04/10/2019 at 18:26.
Pushed by scmsync into branch 'Applications/19.08'.

enable hidpi auto scaling

M  +4    -3    src/main.cpp

https://commits.kde.org/konsole/54820e0ff2745add8b8353f538ad67d66b657d49

Created attachment 123201 [details]
screen recording on Neon unstable edition, scale factor 1.25

Artifacts occur on Neon unstable edition when 1.25 scale factor is used.
Furthermore, there is a regression: sometimes a url disappears on mouseover. I recorded a video showing such issues.

The artifacts are expected, they won't go away until Qt fixes

https://bugreports.qt.io/browse/QTBUG-78963

or somebody finds an other reason for them that is fixable.

For the disappearing url: As I only disabled anti-aliasing in all my commits below, that can't be because of this bug.

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 390451

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

I have the same problem on my Dell XPS 13" FHD(9350).

Scale Factor: 1.4

KDE Plasma: 5.16.5
KDE Frameworks: 5.61.0

QT Version: 5.12.5

Created attachment 123973 [details]
attachment-8164-0.html

The current KDE release 5.17.3. This bug has been partially fixed. Your distro is running 5.16.5 which does not include any of these fixes, so posts like your just add noise to an already messy report. If you want to be helpful, try with KDE Neon, Arch, or OpenSuse Tumbleweed.

-Luke


________________________________
From: frsposito <bugzilla_noreply@kde.org>
Sent: Saturday, November 16, 2019 2:08 PM
To: lukebenes@hotmail.com <lukebenes@hotmail.com>
Subject: [konsole] [Bug 373232] Horizontal lines with fractional HiDPI scaling

https://bugs.kde.org/show_bug.cgi?id=373232

frsposito <francescoesposito.in@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |francescoesposito.in@gmail.
                   |                            |com

--- Comment #141 from frsposito <francescoesposito.in@gmail.com> ---
I have the same problem on my Dell XPS 13" FHD(9350).

Scale Factor: 1.4

KDE Plasma: 5.16.5
KDE Frameworks: 5.61.0

QT Version: 5.12.5

--
You are receiving this mail because:
You voted for the bug.
You reported the bug.

(In reply to lukebenes from comment #142)
> Created attachment 123973 [details]
> attachment-8164-0.html
> 
> The current KDE release 5.17.3. This bug has been partially fixed. Your
> distro is running 5.16.5 which does not include any of these fixes, so posts
> like your just add noise to an already messy report. If you want to be
> helpful, try with KDE Neon, Arch, or OpenSuse Tumbleweed.
> 
> -Luke
> 
> 
> ________________________________
> From: frsposito <bugzilla_noreply@kde.org>
> Sent: Saturday, November 16, 2019 2:08 PM
> To: lukebenes@hotmail.com <lukebenes@hotmail.com>
> Subject: [konsole] [Bug 373232] Horizontal lines with fractional HiDPI
> scaling
> 
> https://bugs.kde.org/show_bug.cgi?id=373232
> 
> frsposito <francescoesposito.in@gmail.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |francescoesposito.in@gmail.
>                    |                            |com
> 
> --- Comment #141 from frsposito <francescoesposito.in@gmail.com> ---
> I have the same problem on my Dell XPS 13" FHD(9350).
> 
> Scale Factor: 1.4
> 
> KDE Plasma: 5.16.5
> KDE Frameworks: 5.61.0
> 
> QT Version: 5.12.5
> 
> --
> You are receiving this mail because:
> You voted for the bug.
> You reported the bug.

Hello!
I have:
 - KDE Plasma 5.17.3
 - Global scale factor: 1.8

And bug is still remains.

https://yadi.sk/i/FRLkeAXuC2OQ-Q
https://yadi.sk/i/PLRcgaOejNQ_sw

I have:

 - KDE Plasma 5.17.3
 - Global scale factor: 1.1k

And bug is still remains.

Bug is still remains with scale factor of 1.3

Created attachment 124101 [details]
konsole menu artifacts and lines

Comment on attachment 124101 [details]
konsole menu artifacts and lines

Dell XPS 15:

Operating System: KDE neon 5.17
KDE Plasma Version: 5.17.3
KDE Frameworks Version: 5.64.0
Qt Version: 5.13.2
Kernel Version: 5.0.0-36-generic
OS Type: 64-bit
Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz
Memory: 31.1 GiB of RAM

Comment on attachment 124101 [details]
konsole menu artifacts and lines

Operating System: KDE neon 5.17
KDE Plasma Version: 5.17.3
KDE Frameworks Version: 5.64.0
Qt Version: 5.13.2
Kernel Version: 5.0.0-36-generic
OS Type: 64-bit
Processors: 12 × Intel® Core™ i7-8750H CPU @ 2.20GHz
Memory: 31.1 GiB of RAM
Fractional Scaling: 1.3

(In reply to Nate Graham from comment #140)
> 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.

Was  0.0625 found by trial and error? Any experts in floating point math on this list? Wondering if this is the right magic number or if the correct solution is to convert everything to integer math. If so, what would the right magic number/flick[1] be for this case.  

[1] https://mux.com/blog/in-defense-of-flicks-or-how-i-learned-to-stop-worrying-and-love-705600000/

(In reply to lukebenes from comment #149)
> (In reply to Nate Graham from comment #140)
> > 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.
> 
> Was  0.0625 found by trial and error? Any experts in floating point math on
> this list? Wondering if this is the right magic number or if the correct
> solution is to convert everything to integer math. If so, what would the
> right magic number/flick[1] be for this case.  
> 
> [1]
> https://mux.com/blog/in-defense-of-flicks-or-how-i-learned-to-stop-worrying-
> and-love-705600000/

0.0625 is exactly 1/16. This makes it representable in very few bits in binary floating point. This is very different from 0.1 which must be approximated and that approximation contains information in all of the mantissa bits. For example, in 64-bit floating point 0.1 + 0.1 + 0.1 == 0.30000000000000004. This kind of very slight difference is an issue since it tends to *change* as you add or subtract from the number. This means that certain arithmetic is "numerically unstable" meaning (roughly) that small errors due to floating point compound through an algorithm. For example,

(0.1 - 1024 + 1024) / 0.1 = 1.0000000000002274
(0.1 - 1100 + 1100) / 0.1 - 0.9999999999990905

However if we use 1/16 this is much better,

>>> (0.0625 - 1024 + 1024) / 0.0625
1.0
>>> (0.0625 - 1100 + 1100) / 0.0625
1.0

This is where the "various Qt and X11 bugs" come in: display code should not do much in floating point (as you recommend), or it should avoid accumulating values and even be careful with multiplication. However, the code probably does all these things (accumulating the height of lines to find where the next line should be placed maybe be part of this specific bug). 

By limiting using scaling factors that are less susceptible to these issues will help avoid the bugs. I don't know how 1/16 was chosen though, using 1/32 or 1/64 would have similar results but have less of a safety margin to resist numerical instability. That said, I think 1/16 is plenty small for real use. I doubt any one needs a scaling of 33/32 and will not be happy with 34/32 = 17/16.

*** Bug 414752 has been marked as a duplicate of this bug. ***

Solution for my case:
1. 2560 / 1.3 = 1969,23076923
2. Round to 1970
3. 2560 / 1970 = 1,29949238579
4. Open ~/.config/kdeglobals and set it manually:

[KScreen]
ScaleFactor=1,29949238579
ScreenScaleFactors=eDP-1=1.0;HDMI-1=1,29949238579;DP-1=1,29949238579;HDMI-2=1,29949238579;

It solves the issue.

Created attachment 124342 [details]
Vertical lines after testing the idea of Andrew.

(In reply to Andrew from comment #152)
> Solution for my case:
> 1. 2560 / 1.3 = 1969,23076923
> 2. Round to 1970
> 3. 2560 / 1970 = 1,29949238579
> 4. Open ~/.config/kdeglobals and set it manually:
> 
> [KScreen]
> ScaleFactor=1,29949238579
> ScreenScaleFactors=eDP-1=1.0;HDMI-1=1,29949238579;DP-1=1,29949238579;HDMI-
> 2=1,29949238579;
> 
> It solves the issue.

This is indeed a nice hack to get rid of the horizontal lines. However, after applying it I noticed other artifacts like vertical lines.

> > It solves the issue.
> 
> This is indeed a nice hack to get rid of the horizontal lines. However,
> after applying it I noticed other artifacts like vertical lines.

As far I can see it, two individual scaling factors would be required for the vertical and the horizontal axis to make this actually work.

Postix: You are right, I didn't consider vertical pixels, but in my resolution (2560x1440) I don't see any artifacts. I think for other resolutions you can just iterate over integer values to find acceptable result.

(In reply to Andrew from comment #152)
> Solution for my case:
> 1. 2560 / 1.3 = 1969,23076923
> 2. Round to 1970
> 3. 2560 / 1970 = 1,29949238579
> 4. Open ~/.config/kdeglobals and set it manually:
> 
> [KScreen]
> ScaleFactor=1,29949238579
> ScreenScaleFactors=eDP-1=1.0;HDMI-1=1,29949238579;DP-1=1,29949238579;HDMI-
> 2=1,29949238579;
> 
> It solves the issue.

Shouldn't that be "1.299"? (. vs ,); I haven't looked at the code, but "1,299" is most likely either going to be treated as invalid or as just integer 1.

(In reply to Ahmad Samir from comment #156)
> Shouldn't that be "1.299"? (. vs ,); I haven't looked at the code, but
> "1,299" is most likely either going to be treated as invalid or as just
> integer 1.

Locale affects parsing as well as printing, so in the, say, de_DE locale a ',' may well parse as a decimal separator instead of a "thousands" separator. This is true of most European locales I think. So the original poster of the config was probably correct for their own machine, but for yours you might need to use a '.' (if you are in en_US for instance).

(In reply to Arthur Peters from comment #157)
> 
> Locale affects parsing as well as printing, so in the, say, de_DE locale a
> ',' may well parse as a decimal separator instead of a "thousands"
> separator. This is true of most European locales I think. So the original
> poster of the config was probably correct for their own machine, but for
> yours you might need to use a '.' (if you are in en_US for instance).

Locale-dependent config files are probably not a good idea. If the user changes his locale settings, suddenly all config files become invalid.

(In reply to Andrew from comment #152)
> Solution for my case:
> 1. 2560 / 1.3 = 1969,23076923
> 2. Round to 1970
> 3. 2560 / 1970 = 1,29949238579
> 4. Open ~/.config/kdeglobals and set it manually:
> 
> [KScreen]
> ScaleFactor=1,29949238579
> ScreenScaleFactors=eDP-1=1.0;HDMI-1=1,29949238579;DP-1=1,29949238579;HDMI-
> 2=1,29949238579;
> 
> It solves the issue.

I have resolution of 1920x1080 on XPS13.  Scale factor I set in Plasma is 1.2 which gives integral values.  I still can see horizontal lines.

> I have resolution of 1920x1080 on XPS13.  Scale factor I set in Plasma is 1.2 > which gives integral values.  I still can see horizontal lines.

1.2 is no proper float.

Try 1.25 or some other 1/2^x number.

Arthur Peters did some good explaining below. 

Our stack isn't build in a way that it properly works with such numbers.

I use here 1.5 and for me, this is more or less artifact free, same for 1.25.

There are still some issues (like some artifacts after selection), but I am unable to fix these and my Qt bug is still unresolved as nobody found the real reason for these ones.

(In reply to Christoph Cullmann from comment #160)
> > I have resolution of 1920x1080 on XPS13.  Scale factor I set in Plasma is 1.2 > which gives integral values.  I still can see horizontal lines.
> 
> 1.2 is no proper float.
> 
> Try 1.25 or some other 1/2^x number.

Tried 1.25 with no luck.

This is part of my ~/.config/kdeglobals:

[KScreen]
ScaleFactor=1.25
ScreenScaleFactors=eDP-1=1.25;DP-1=1.25;DP-2=1.25;DP-2-1=1.25;DP-2-2=1.25;DP-2-3=1.25;

Did I do anything wrong? When I modified this file, I also rebooted my pc.

Any suggestion, please?

Qt 5.14 has been released with updated high-DPI support:

https://lists.qt-project.org/pipermail/development/2019-September/037434.html

The changes include:

* Support for fractional device pixel ratios (e.g. Windows 150%)
* Support per-screen DPI in more places like QStyle
* Cleanup of configuration API and options.
* Platform plugins: 
* Scale factor computation rounding policy options.
* Environment variables for development and testing:
* Manual test to display screen/DPI/DPR config and environment variables.

(In reply to Lastique from comment #158)
> (In reply to Arthur Peters from comment #157)
> > 
> > Locale affects parsing as well as printing, so in the, say, de_DE locale a
> > ',' may well parse as a decimal separator instead of a "thousands"
> > separator. This is true of most European locales I think. So the original
> > poster of the config was probably correct for their own machine, but for
> > yours you might need to use a '.' (if you are in en_US for instance).
> 
> Locale-dependent config files are probably not a good idea. If the user
> changes his locale settings, suddenly all config files become invalid.

Yes, using localized number formatting in config files is indeed a terrible idea, and it's most likely an oversight rather than a deliberate design decision.

If it's really the case, you should file a separate bug for this. I have no idea how it could be fixed without breaking existing configs, though :-(

Just to clarify things, KConfig, AFAICS, doesn't take numbers with locale dependant notation; so "1.25" is a double number, whereas "1,25" is not.

I have compiled Konsole 20.03.70 (git master) locally against Qt 5.14.0 on Arch Linux (Manjaro) and don't see any more horizontal lines with a scaling of 1.5. 

To me the issue seems to be resolved finally. :-)

Definitely not resolved.

The following commit (https://cgit.kde.org/konsole.git/commit/?id=54820e0ff2745add8b8353f538ad67d66b657d49) is causing weird font showing inside konsole.

Commenting `QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true);` in `src/main.cpp` or setting it to `false` or launching the application with `QT_AUTO_SCREEN_SCALE_FACTOR=0` fixes the issue.

See also here: https://bbs.archlinux.org/viewtopic.php?pid=1881713

Not sure if it's the same bug but I have also a weird font rendering since a recent plasma update,

I use archlinux, all KDE softwares (konsole, kate etc...) has a bad font rendering, the height of the fonts seem a little smaller than usual, and are less sharp than usual.

I have a 24 inch monitor 1920x1080 pixels, I don't see manually dpi.

As a workaround I set QT_AUTO_SCREEN_SCALE_FACTOR to 0.

My system uses a DPI value of 96 :

$ xdpyinfo | grep -B2 resolution
screen #0:
  dimensions:    1920x1080 pixels (508x285 millimeters)
  resolution:    96x96 dots per inch

$ xdpyinfo | grep dots
  resolution:    96x96 dots per inch

Created attachment 125013 [details]
difference with QT_AUTO_SCREEN_SCALE_FACTOR enabled/disabled in konsole

Here is a comparison in konsole when QT_AUTO_SCREEN_SCALE_FACTOR is set to 1 (slightly blurry fonts), and when QT_AUTO_SCREEN_SCALE_FACTOR is set to 0 (sharp fonts, better rendering).

Potomac, are you sure it was a Plasma update that broke it? The net is full of font rendering regression reports since Qt was updated to version 5.14.0.

(In reply to Christoph Feck from comment #170)
> Potomac, are you sure it was a Plasma update that broke it? The net is full
> of font rendering regression reports since Qt was updated to version 5.14.0.

Yes, the problem started with the update of plasma (5.17.4 to 5.17.5) and KDE softwares (19.12.0 -> 19.12.1),

on these new versions the "high dpi support" has been enabled by kde developers, which triggers problems on my configuration (24 inch monitor 1920x1080, DPI 96, graphic card : amd radeon HD4650 pcie, radeon driver open source) :

+    // enable high dpi support
+    QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true);
+    QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true);
+

https://cgit.kde.org/konsole.git/commit/?id=54820e0ff2745add8b8353f538ad67d66b657d49

(In reply to Potomac from comment #171)
> (In reply to Christoph Feck from comment #170)
> > Potomac, are you sure it was a Plasma update that broke it? The net is full
> > of font rendering regression reports since Qt was updated to version 5.14.0.
> 
> Yes, the problem started with the update of plasma (5.17.4 to 5.17.5) and
> KDE softwares (19.12.0 -> 19.12.1),

See https://bugreports.qt.io/browse/QTBUG-80967

(In reply to Wolfgang Bauer from comment #172)
> (In reply to Potomac from comment #171)
> > (In reply to Christoph Feck from comment #170)
> > > Potomac, are you sure it was a Plasma update that broke it? The net is full
> > > of font rendering regression reports since Qt was updated to version 5.14.0.
> > 
> > Yes, the problem started with the update of plasma (5.17.4 to 5.17.5) and
> > KDE softwares (19.12.0 -> 19.12.1),
> 
> See https://bugreports.qt.io/browse/QTBUG-80967

In short, it is indeed triggered by enabling high dpi support in konsole (only with Qt 5.14.0 though), but that doesn't mean enabling high dpi support in konsole is wrong.
The real issue is elsewhere.

The new font rendering issue is also reported as bug#416001 btw, so please let's keep it out of here. It has nothing to do with the original problem.

Btw, forgot to mention this:
(In reply to Potomac from comment #171)
> (In reply to Christoph Feck from comment #170)
> > Potomac, are you sure it was a Plasma update that broke it? The net is full
> > of font rendering regression reports since Qt was updated to version 5.14.0.
> 
> Yes, the problem started with the update of plasma (5.17.4 to 5.17.5) and
> KDE softwares (19.12.0 -> 19.12.1),
> 
> on these new versions the "high dpi support" has been enabled by kde
> developers, which triggers problems on my configuration (24 inch monitor
> 1920x1080, DPI 96, graphic card : amd radeon HD4650 pcie, radeon driver open
> source) :
> 
> +    // enable high dpi support
> +    QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true);
> +    QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true);
> +
> 
> https://cgit.kde.org/konsole.git/commit/
> ?id=54820e0ff2745add8b8353f538ad67d66b657d49

This change was in konsole 19.12.0 already, not in the update to 19.12.1...

I have a similar problem in Gwenview, but a lot worse. Sometimes it's black lines, sometimes it's just lines that should be strait are not.
Example Printscreen: https://i.imgur.com/LlSlocG.png

(In reply to tuor from comment #176)
> I have a similar problem in Gwenview, but a lot worse. Sometimes it's black
> lines, sometimes it's just lines that should be strait are not.
> Example Printscreen: https://i.imgur.com/LlSlocG.png

Does this happen especially when you zoom and move around in the image and especially for PNGs? Then it's probably related to https://bugs.kde.org/show_bug.cgi?id=414776

Created attachment 125850 [details]
konsole 19.12.2, display scale 125%

This bug persists with konsole 19.12.2, display scale 125%.

Operating System: Arch Linux 
KDE Plasma Version: 5.18.0
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1

(In reply to Patrick Silva from comment #178)
> This bug persists with Konsole 19.12.2, display scale 125%.

Can attest. Same display scale, versions are the same for everything, except that my Qt is 5.13.2, atop KDE Neon.

It's as if when calculating the dirty regions, they are off by one when filling the background. They end up transparent for me.

Yes, see https://bugreports.qt.io/browse/QTBUG-78963

I see no way how we can workaround that (beside if we start to always repaint the full widget...)

Created attachment 126018 [details]
patch: expand background rendering by 1px

Here's the patch I whipped up in ten minutes. Rendering is no off by 1px around all text with non-default background. But the annoying lines are gone. #worksforme

Maybe there could be a way of calculating when Qt is going to screw up and round down the rendered rectangle size. That would depend on the rectangle's geometry, and would add a pixel of height or width only if that is necessary. 

If such a patch would be accepted, I'll put in the work. Otherwise, I'll just stick to my patched kinda-works-but-not-technically-correct version.

(In reply to Lucas Pires Camargo from comment #181)
> Here's the patch I whipped up in ten minutes. Rendering is _NOW_ off by 1px
> around all text with non-default background.

To clarify: this patch screws with color background rendering of the text a bit. But solves my problem and might be of use to someone else.

Lucas & Christoph,
How does the https://github.com/qt/qtbase/commit/19f29802bf7daafacd0fd824c2a1349e80eac536
off-by-one fix relate to Lucas' patch? Unfortunately this landed in qt 5.15, so it didn't make it into KDE 5.18. 

There seems to be 2 issues causing line artifacts with scaling:
1) Underneath windows bleeding through (fixed by Lucas?)
2) Artifacts remaining after selecting text/screen scrolling. (fixed in qt 5.15?)

Is my understanding correct?

I'm not quite sure. For painting the background, it seems like the clip region is always null or the entire area inside the borders. Figured that out by printing out the QRegion via qDebug().

So there seems to be a rounding problem also when rendering rectangles, unrelated to the clip region.  My patch fixes it for me. And after adjusting it just now, it's "much less wrong" by expanding the rectangle to be painted as the background like so:

QRect expandedRect{ rect.x(), rect.y(), rect.width(), rect.height()+1 };
    
So, only 1px of added height is needed to get rid of the spurious horizontal lines. If I figured out a way to calculate when this is going to happen, it'd be pixel-perfect, I guess.

I still get spurious artifacts when selecting/deselecting text, but not scrolling. I can't test the Qt 5.15 fix right now with my current setup. After playing around with it a bit, I figured the only solution to this whole shebang if figuring out how to adjust the coordinates on bounding rects of the lines in a way that after scaling, they align perfectly with the physical pixel grid, not overlapping not leaving gaps. I'm trying to figure that out, but I'm not at all familiar with Konsole's codebase, so this might take a while.

I know nothing about how the code works, but doesn't incrementing height have the potential to corrupt the surrounding previously rendered content when the increment is not needed?

(In reply to Lastique from comment #185)
> I know nothing about how the code works, but doesn't incrementing height
> have the potential to corrupt the surrounding previously rendered content
> when the increment is not needed?

That's true. And it does. That

Whoops. I posted midway on accident.

(In reply to Lastique from comment #185)
> I know nothing about how the code works, but doesn't incrementing height
> have the potential to corrupt the surrounding previously rendered content
> when the increment is not needed?

That's right. And it does. That's why I said this patch is not suitable for merging. But it might be helpful for people like me that are willing to trade whole-window artifacts for slightly incorrect rendering of text with colored backgrounds. For most people using fractional scaling, I guess that the off-by-one pixel artifacts are much less jarring.

I guess what I really need to do is test with the latest Qt and attempt a proper fix from that. I'll try to figure that out. If anyone can point out to me how to do that (CMake arguments for konsole?) that'd be much appreciated.

*** Bug 420042 has been marked as a duplicate of this bug. ***

*** Bug 419910 has been marked as a duplicate of this bug. ***

even worse - with F31 + latest updates I get not only horizontal lines but blinking / missing text. it makes konsole almost unuseable.

https://bugreports.qt.io/browse/QTBUG-82601

The patch attached there fixed the issue for me.

*** Bug 420394 has been marked as a duplicate of this bug. ***

(In reply to Roberth Sjonøy from comment #191)
> https://bugreports.qt.io/browse/QTBUG-82601
> 
> The patch attached there fixed the issue for me.

It fixed it for me too.

*** Bug 421285 has been marked as a duplicate of this bug. ***

With the latest version of Konsole and Qt 5.14.1 and a 125% scale factor, I don't see any lines at all. \o/

Can anyone confirm?

It's still happening here. :(
Konsole 20.04.1,  125% scale factor.

Operating System: Arch Linux 
KDE Plasma Version: 5.18.90
KDE Frameworks Version: 5.70.0
Qt Version: 5.15.0 rc2

Yes, also just updated my desktop to the kde-unstable repo in Arch and continue to see this bug.

Operating System: Arch Linux 
KDE Plasma Version: 5.18.90
KDE Frameworks Version: 5.70.0
Qt Version: 5.15.0 rc2

*** Bug 421692 has been marked as a duplicate of this bug. ***

*** Bug 422220 has been marked as a duplicate of this bug. ***

KDE Neon with Qt 5.14.2.

Konsole is giving me these random lines at 175% scale factor.

I have been seeing the problem as well, using a 4K screen, Ubuntu Focal / x11 on Intel gpu, with scale=1.7 set in kde display settings. AFAIK it doesn't matter much which scale is used if it's fractional.

I noticed the mention of qt5.15 earlier and so have built qt(head 5.15) and kde(head master) from latest sources to see if this fixes the problem. I eventually built the whole of qt except Krita and SignonD. This build is better compared to kubuntu focal, slightly, but does not fix it (kubuntu shows many more places with damage, not just konsole).

I did a test just now: in dark-background vim with the cursor at the bottom of the screen, autorepeat-uparrow to the screen top results in multiple horizontal lines under the cursor. autorepeat down-arrow tends to clear them, though not always.

I also often see a vertical line to the right of the cursor when typing at a prompt, though for some reason this tends not to remain afterwards. It sort of looks like I've got both a horizontal underline cursor and a vertical one, though the vertical is one char offset.

With a white window (new firefox tab) behind Konsole, the lines in the konsole window are white. iconising the window behind means the lines in konsole change colour to the desktop wallpaper -- i.e. the lines are actually transparent, not opaque.

I had a look at the relevant code, particularly TerminalDisplay.cpp. There are a few uses of QRectF in there, which IIRC is a floating point rectangle. I'm not sure how hidpi works -- does it result in fractional pixel addresses, which might require floats? Is the problem possibly that more QRects and QPoints in the code should be QRectF?

Confirm. Ubuntu 20.04, global scale 125%

*** Bug 423733 has been marked as a duplicate of this bug. ***

I am experiencing the problem with Yakuake, scale 125%
Xorg session
Plasma 5.18.5
KDE Frameworks 5.70.0
Qt 5.14.2
AMD Radeon RX480
Kernel 5.7.6-201.fc32.x86_64

FWIW, I've found a combination of scale and fonts that make the lines not appear: 11pt Hack font plus 125% scale on an FHD screen or 250% scale on a 4K screeen.

Hi all,
I have a QHD display 2560x1440 and set the scaling in KDE settings to 125%.
Now the lines appears in Konsole.
I tied scaling also 150% and 175% with same result.
Set the font to Hack 11pt, also 12pt, tied different color scheme, solid/image background with no difference.

I'm running openSUSE Tumbleweed with:
KDE Plasma: 5.19.2
KDE Frameworks: 5.71.0
QT: 5.15.0
GPU: Mesa DRI Intel® Iris® Plus Graphics 640
Konsole: 20.04.2

Created attachment 130177 [details]
125% DPI scaling on 1920x1080 screen

My two cents:
* horizontal lines in menus
* horizontal lines in terminal
* blurry icons in the toolbars
* blurry controls

Linux/KDE Plasma: KDE neon 5.19 User Edition
KDE Plasma Version: 5.19.3
KDE Frameworks Version: 5.72.0
Qt Version: 5.14.2

Just to add one thing I noticed.
If I set the scale to 125% in settings then I see the lines appearing.
But If I set the force DPI of font and set he value from 96 to 120 (125% scaling) in KDE font settings then I get pretty much usable scaling and I don't get any lines anywhere.

Created attachment 130234 [details]
Search field in the System Settings with 125% DPI scale

*** Bug 424412 has been marked as a duplicate of this bug. ***

(In reply to Nate Graham from comment #205)
> FWIW, I've found a combination of scale and fonts that make the lines not
> appear: 11pt Hack font plus 125% scale on an FHD screen or 250% scale on a
> 4K screeen.

Confirmed. 4k + 240% dpi.

Depend on selected font, line appeared/disappeared.

(In reply to YCH from comment #211)
> (In reply to Nate Graham from comment #205)
> > FWIW, I've found a combination of scale and fonts that make the lines not
> > appear: 11pt Hack font plus 125% scale on an FHD screen or 250% scale on a
> > 4K screeen.
> 
> Confirmed. 4k + 240% dpi.
> 
> Depend on selected font, line appeared/disappeared.

EDIT: 4k + 250% scaling + 240% force font dpi

Created attachment 130908 [details]
Patchfile of debugging code intended to assist finding terminal display bugs.

I did some more work trying to understand the issue yesterday and as part of that created some debug prints to show what is happening. Note that the debug includes a macro "delay()" which was intended to slow things down enough to watch what happens. Change the delay amount or remove the call to delay() as appropriate.

I had previously presumed the bug was an 'off-by-one' error but the debug code indicates that updates do happen on the appropriate pixel areas. I no longer think this explains it. However the lines do appear more reliably when the drawTextFragments() call isn't followed by anything else.

I think, though at present this is a guess, that the problem is a rounding error. If internally the scaling code is rounding down rather than up, a fractional half or third of a pixel could be reduced to 0, and that when then scaled up that results in whole rows or columns of pixels not written. I say this is a guess because I haven't yet found the evidence for it.

What is also obvious from the resulting trace is that there is a lot of apparently unnecessary repainting going on. Partly this is because ::paintEvent is being called with a damage rectangle equal to the terminal widget size, for reasons I cannot yet explain.

It would be good to eliminate the excessive repainting because it partly masks the actual issues, and partly because it is just making everything slower.

I still think is:

https://bugreports.qt.io/browse/QTBUG-78963

See for more details

https://cullmann.io/posts/kde-qt-highdpi-scaling/

I traced down the paint stuff, too, and think we paint the "right" rectangles but that is then afterwards not properly "clipped".

If you can provide them with some way to reproduce, that would be nice, I did fail.

On 16/08/2020 13:16, Christoph Cullmann wrote:
> https://bugs.kde.org/show_bug.cgi?id=373232
>
> --- Comment #215 from Christoph Cullmann <cullmann@kde.org> ---
> I still think is:
>
> https://bugreports.qt.io/browse/QTBUG-78963
>
> See for more details
>
> https://cullmann.io/posts/kde-qt-highdpi-scaling/
>
> I traced down the paint stuff, too, and think we paint the "right" rectangles
> but that is then afterwards not properly "clipped".
>
> If you can provide them with some way to reproduce, that would be nice, I did
> fail.
>

Well it's not too hard to demonstrate that at least some of the QRects 
are correct with my debug patches.

I find vim is quite good at reliably producing and erasing extraneous 
lines, so I'll give it a go.

Ruth

Something I have noticed that I haven't sen mentioned is that the "lines" are actually more like "tears" in the program. On a large monitor I notice my wallpaper pattern in the "lines".

I am using Kubuntu 20.04, 4k monitor, 125% scaling, problems in Konsole and Kate.

Ryan, you are correct. The 'lines' are actually areas of the window that are transparent, and when the compositor then does its thing, those transparent areas show whatever is behind the konsole window.

My investigations (see previous comments) suggest this is a maths error (probably inappropriate rounding) in the Qt drawing code, probably exacerbated by the way Konsole does its painting.

Just for the record, I *have* seen the same problems in other places, though they are much rarer.

*** Bug 427781 has been marked as a duplicate of this bug. ***

Created attachment 132434 [details]
attachment-24456-0.html

I just want to say thank you to the KDE team (and all the others) who are
working on this issue. It's great to see progress being made.

On Thu, Oct 15, 2020 at 9:55 PM Patrick Silva <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=373232
>
> Patrick Silva <bugseforuns@gmx.com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |99andri12@gmail.com
>
> --- Comment #219 from Patrick Silva <bugseforuns@gmx.com> ---
> *** Bug 427781 has been marked as a duplicate of this bug. ***
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You voted for the bug.

I really think bug https://bugs.kde.org/show_bug.cgi?id=422798 is related to this one. I included a screen-recording in this bug. 
I wasn't aware that my system "scaled" the output to the screen but is was (very little). After I set the scaling to 100% the ugly distortion was completely gone.

Created attachment 132847 [details]
Horizontal lines with fractional HiDPI scaling

This bug still in FreeBSD 12.2.
KDE 5.75.0
QT 5.15.0
Konsole 20.08.2

And, Ykla, what happens if you set scene scaling to 100 %? Just out of curiositeit...

I Ment "screen scaling" in the precious comment...

I am NO LONGER experiencing the problem after upgrading to Plasma 5.20.x
KDE Frameworks 5.75.0
Qt 5.15.1
Xorg session.
I will continue testing in next days to see if the problem is really gone

I have the same version and still experiencing the issue.  Fresh reboot.

175% scaling on 4k monitor.

(In reply to Ryein Goddard from comment #227)
> I have the same version and still experiencing the issue.  Fresh reboot.
> 
> 175% scaling on 4k monitor.

I should add my Qt version is 5.15.0 not 5.15.1... perhaps that is the key?

PK,set 100% is normal, no horizontal lines.

Created attachment 133076 [details]
attachment-14453-0.html

I no longer get this:

Konsole: v20.08.1
QT: v5.15.1
Scaling: 1.25x @ on a 14" 1440p display.

On Thu, Nov 5, 2020, at 9:34 AM, Ryein Goddard wrote:
> https://bugs.kde.org/show_bug.cgi?id=373232
> 
> --- Comment #228 from Ryein Goddard <ryein@live.com> ---
> (In reply to Ryein Goddard from comment #227)
> > I have the same version and still experiencing the issue.  Fresh reboot.
> > 
> > 175% scaling on 4k monitor.
> 
> I should add my Qt version is 5.15.0 not 5.15.1... perhaps that is the key?
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

I don't see any more lines too on

Operating System: Manjaro Linux
KDE Plasma Version: 5.20.2
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.1
Kernel Version: 5.9.3-1-MANJARO

for scaling 1.5 both on X11 and Wayland.


However on a second laptop (with a lower resolution namely FullHD) I saw only some lines when making a multi-line selection in Konsole on Wayland. On X11 there were none in this case.

I agree, latest KDE neon (Plasma 5.20.3, Frameworks 5.75.0, Qt 5.15.1) with 125% scaling - no more lines. Wow!

But, unfortunately, there are still problems with blurry icons and some parts of the UI elements.

Yes I can verify horizontal lines are now gone in konsole for KDE Neon.

Still problems with vertical lines though, but this isn't as annoying.

Qt 5.15.1 fixed it, confirmed by several reporters; closing.

> problems with vertical lines

Bug 425408?

Yep, true, seems to be fine here, too.

My QT bug is still open, if I find some time will try to search which commit fixed that.

*** Bug 428898 has been marked as a duplicate of this bug. ***

Created attachment 133372 [details]
attachment-1008-0.html

to me its still not working if the display is scaled to 150%

On Sun, 15 Nov 2020 at 17:00, Patrick Silva <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=373232
>
> Patrick Silva <bugseforuns@gmx.com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |m.seidel1@gmx.de
>
> --- Comment #236 from Patrick Silva <bugseforuns@gmx.com> ---
> *** Bug 428898 has been marked as a duplicate of this bug. ***
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

andrew, could you please give some information about your system where it still doesn't work?
(Plasma/QT/Screen Size/Resolution/Driver/X11/Wayland etc.)

Created attachment 133379 [details]
attachment-30565-0.html

Kde Plasma : 5.18.5
Kde Framework Version : 5.68.0
Qt Version 5.12.8
Kervel Version : 5.4.0-52-generic
im using X11.

The display is 4k scaled to 1920x1080 with 150%  scale.

On Sun, 15 Nov 2020 at 22:00, Postix <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=373232
>
> --- Comment #238 from Postix <postix@posteo.eu> ---
> andrew, could you please give some information about your system where it
> still
> doesn't work?
> (Plasma/QT/Screen Size/Resolution/Driver/X11/Wayland etc.)
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

This issue was fixed in Qt 5.15.1.

Created attachment 133380 [details]
attachment-32190-0.html

sorry, i seen now thank you

On Mon, 16 Nov 2020 at 14:31, Christoph Feck <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=373232
>
> --- Comment #240 from Christoph Feck <cfeck@kde.org> ---
> This issue was fixed in Qt 5.15.1.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

Corruption of konsole when using nwipe which uses ncurses. Doesn't appear to happen in other terminals only on konsole. Please see the nwipe issue here https://github.com/martijnvanbrummelen/nwipe/issues/305 and especially the video that shows the corruption on the bottom line of the screen. These box characters also randomly appear in the main window of nwipe.

100% reproducible on Konsole v20.04.3 (KDE 5.19.4) (QT 5.14.2).

According to the most recent comments this is fixed in QT v 5.15.1 so when I get a moment I will upgrade and confirm whether it has fixed this for me.

(In reply to Nick from comment #242)
> Corruption of konsole when using nwipe which uses ncurses. Doesn't appear to
> happen in other terminals only on konsole. Please see the nwipe issue here
> https://github.com/martijnvanbrummelen/nwipe/issues/305 and especially the
> video that shows the corruption on the bottom line of the screen. These box
> characters also randomly appear in the main window of nwipe.
> 
> 100% reproducible on Konsole v20.04.3 (KDE 5.19.4) (QT 5.14.2).
> 
> According to the most recent comments this is fixed in QT v 5.15.1 so when I
> get a moment I will upgrade and confirm whether it has fixed this for me.

Further to my comments above: The terminal corruption as shown in the two attached images (vertical, horizontal or corner box characters or lines and incorrect character color background) is not fixed by QT v5.15.1.

I've come to the conclusion it is still a Konsole issue because both Konsole and cool-retro-term which uses a QML port of qtremwidget (Konsole) also shows the same problem almost (no line characters but incorrect background color).

While the following terminal emulators DO NOT show this problem, tmux, terminology, terminator, kitty, guake, stterm or st, rxvt-unicode.

Created attachment 135511 [details]
Corruption on bottom line to the right of the image

Konsole snapshot of corruption on the bottom line to the right. Not fixed by QT 5.15.1. This corruption only occurs in Konsole and cool-retro-term which is based on konsole qtermwidget. The corruption does not occur in the following none KDE terminal emulators, tmux, terminology, terminator, kitty, guake, stterm or st, rxvt-unicode.

Created attachment 135512 [details]
Corruption bottom line, on the right of screen, incorrect background color

cool-retro-term which is based on qtermwidget (Konsole) snapshot of corruption on the bottom line to the right. Not fixed by QT 5.15.1. This corruption only occurs in Konsole and cool-retro-term which is based on konsole qtermwidget. The corruption does not occur in the following none KDE terminal emulators, tmux, terminology, terminator, kitty, guake, stterm or st, rxvt-unicode.

The issue you're describing looks like a real issue, but it's not the same as this one. Can you please file a new bug report? Thanks!

(In reply to Nate Graham from comment #246)
> The issue you're describing looks like a real issue, but it's not the same
> as this one. Can you please file a new bug report? Thanks!

Ok, will do.

(In reply to Nate Graham from comment #246)
> The issue you're describing looks like a real issue, but it's not the same
> as this one. Can you please file a new bug report? Thanks!

Done https://bugs.kde.org/show_bug.cgi?id=432669

(In reply to Nate Graham from comment #250)
> That's almost certainly a different bug, especially if you're using the
> Wayland session. Update to Plasma 5.27.2 once it's released in a few days
> and see if that helps. If it doesn't, please submit a new bug report. Thanks!

I am using Xorg session. Will check again once 5.27.2 is out. Thank you!

I still get horizontal lines (again) in Konsole on 5.27.2 on Wayland w/ fractional scaling. Should I open a new bug report?

It's most likely Bug 465158.

(In reply to Nate Graham from comment #253)
> It's most likely Bug 465158.

Does not look like Bug 465158 to me. I have not seen horizontal lines on anything other than Konsole. Also, I am seeing the horizontal lines on Xorg, not Wayland.

Then perhaps it isn't that. Please submit a new bug report for it. Thanks!

Got same issue again after upgrade to kubuntu 23.04. Was not present on same system on 22.10.
Plasma: 5.27.4
QT: 5.15.8
KDE: 5.104.0
Scaling: 1.5

Reproducible in Console (same as in "Horizontal lines in Konsole, Fractional Scaling 1.5").

I can still see the horizontal lines. Is my configuration not sufficiently up to date?

Konsole 22.12.3
Plasma: 5.27.4
Qt: 5.15.8
Wayland

I also tried Konsole master with the same result.

This issue is pretty frequent with fractional scaling, so I took 5 minutes to apply a quick patch: https://invent.kde.org/lcarlon/konsole/-/commit/eb11d4fd92996f92d9b37e997f74ec7ac08c25fa.
I'm unable to reproduce the issue with it so far. That is clearly not fixing the bug, it is fixing the result though.

Please note that, even with my patch, I could reproduce a slight issue with underlined font. I had a look and, from what I understand, that may have a different cause.

This is another related patch for the underline: https://invent.kde.org/utilities/konsole/-/merge_requests/843.

Git commit d747635ce1f542bd0e3e278f1f1b95b8b462500d by Matan Ziv-Av, on behalf of Luca Carlon.
Committed on 26/04/2023 at 15:59.
Pushed by matan into branch 'master'.

Fix position and size of the underline

When rendering underlined text in hidpi, the result may be wrong: position
of the underline may be wrong, invisible or with incorrect size.

The patch draws the line using floating point precision and changes the y coord
of the line to respect the Qt coordinate system specs.

M  +3    -7    src/terminalDisplay/TerminalPainter.cpp

https://invent.kde.org/utilities/konsole/commit/d747635ce1f542bd0e3e278f1f1b95b8b462500d

Git commit 1f0cefa40815b00c2ba05453f8774ced180ca113 by Luca Carlon.
Committed on 09/05/2023 at 21:57.
Pushed by hindenburg into branch 'master'.

Invalidate a slightly larger area when scheduling a repaint

In highdpi with fractional scaling factor some lines appear in the
terminal area. This may be the result of areas that should be
refreshed with new content that are not included in the invalidated
area. This commit increases the invalidated area a bit to ensure
the missing area is included.

M  +21   -13   src/terminalDisplay/TerminalDisplay.cpp
M  +19   -0    src/terminalDisplay/TerminalDisplay.h
M  +1    -0    src/terminalDisplay/TerminalPainter.cpp

https://invent.kde.org/utilities/konsole/commit/1f0cefa40815b00c2ba05453f8774ced180ca113

I sent a few patches:

https://invent.kde.org/utilities/konsole/-/commit/87c895cf9759e64829e7a4b7d117b810a0da4da8
https://invent.kde.org/utilities/konsole/-/commit/d747635ce1f542bd0e3e278f1f1b95b8b462500d
https://invent.kde.org/utilities/konsole/-/commit/1f0cefa40815b00c2ba05453f8774ced180ca113
https://invent.kde.org/utilities/konsole/-/commit/fe46ddc09a59141b1c80c4d588df050151dc47a4

with these patches applied, I cannot reproduce the problem anymore in the Konsole terminal view (I can still see horizontal lines elsewhere in Plasma though). Hope this helps.