Bug 373232 - Horizontal lines with fractional HiDPI scaling
Summary: Horizontal lines with fractional HiDPI scaling
Status: CLOSED FIXED
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: 20.08.2
Platform: Neon All
: VHI normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords: usability
: 376039 381646 385928 388539 396457 403251 403911 406770 414752 419910 420042 420394 421285 421692 422220 423733 424412 427781 428898 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-12-03 22:48 UTC by lukebenes
Modified: 2023-09-25 18:47 UTC (History)
137 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot taken on KDE Neon (164.96 KB, image/png)
2016-12-03 22:48 UTC, lukebenes
Details
Screenshot showing the effect in vim in line 54+55 (112.79 KB, image/png)
2017-01-12 08:35 UTC, Horst Schirmeier
Details
after highlighting some text in the terminal (12.13 KB, image/png)
2017-01-17 05:31 UTC, Adam Dymitruk
Details
Horizontal Lines in Kate on Arch Linux (451.97 KB, image/jpeg)
2018-01-05 00:22 UTC, bugreporter11
Details
Still repo on KDE Neon 5.13.3 (164.96 KB, image/png)
2018-07-27 21:33 UTC, lukebenes
Details
Konsole with Midnight Commander garbled (684.47 KB, image/png)
2019-05-28 22:03 UTC, Lastique
Details
Konsole with Midnight Commander correct (211.39 KB, image/png)
2019-05-28 22:10 UTC, Lastique
Details
konsole_photo_prompt_return (190.38 KB, image/jpeg)
2019-05-31 18:13 UTC, Jeffrey Bouter
Details
konsole_ls (310.23 KB, image/jpeg)
2019-05-31 18:15 UTC, Jeffrey Bouter
Details
Konsole Select Text (67.42 KB, image/png)
2019-05-31 19:46 UTC, Jeffrey Bouter
Details
Konsole 19.04.1 ugly lines (180.02 KB, image/png)
2019-06-02 09:16 UTC, Nicolas
Details
Horizontal lines in Vim; Fractional Scaling 1.5; Transparency=True (268.95 KB, image/png)
2019-06-02 10:41 UTC, postix
Details
Horizontal lines in Konsole; Fractional Scaling 1.5; Transparency=True (145.52 KB, image/png)
2019-06-02 10:42 UTC, postix
Details
pre patch with QT_SCALE_FACTOR=1.5 (191.43 KB, image/png)
2019-10-02 20:59 UTC, Christoph Cullmann
Details
post patch with QT_SCALE_FACTOR=1.5 (174.96 KB, image/png)
2019-10-02 20:59 UTC, Christoph Cullmann
Details
screen recording on Neon unstable edition, scale factor 1.25 (3.16 MB, video/webm)
2019-10-15 12:30 UTC, Patrick Silva
Details
attachment-8164-0.html (4.32 KB, text/html)
2019-11-17 18:13 UTC, lukebenes
Details
konsole menu artifacts and lines (168.98 KB, video/mp4)
2019-11-24 15:05 UTC, genbushi
Details
Vertical lines after testing the idea of Andrew. (61.98 KB, image/png)
2019-12-06 14:37 UTC, postix
Details
difference with QT_AUTO_SCREEN_SCALE_FACTOR enabled/disabled in konsole (83.81 KB, image/png)
2020-01-10 12:34 UTC, Potomac
Details
konsole 19.12.2, display scale 125% (244.51 KB, image/png)
2020-02-11 15:57 UTC, Patrick Silva
Details
patch: expand background rendering by 1px (1.31 KB, patch)
2020-02-14 15:22 UTC, Lucas Pires Camargo
Details
125% DPI scaling on 1920x1080 screen (663.29 KB, image/png)
2020-07-16 15:29 UTC, popov895
Details
Search field in the System Settings with 125% DPI scale (43.07 KB, image/png)
2020-07-19 10:14 UTC, popov895
Details
Patchfile of debugging code intended to assist finding terminal display bugs. (38.44 KB, text/plain)
2020-08-16 11:59 UTC, Ruth Ivimey-Cook
Details
attachment-24456-0.html (1.38 KB, text/html)
2020-10-16 17:09 UTC, bugreporter11
Details
Horizontal lines with fractional HiDPI scaling (23.66 KB, image/png)
2020-10-28 19:56 UTC, Roman Mikula
Details
attachment-14453-0.html (1.14 KB, text/html)
2020-11-06 02:57 UTC, Aru Sahni
Details
attachment-1008-0.html (1.26 KB, text/html)
2020-11-15 20:35 UTC, andrew
Details
attachment-30565-0.html (1.11 KB, text/html)
2020-11-16 13:26 UTC, andrew
Details
attachment-32190-0.html (794 bytes, text/html)
2020-11-16 13:45 UTC, andrew
Details
Corruption on bottom line to the right of the image (92.67 KB, image/png)
2021-02-08 17:20 UTC, Nick
Details
Corruption bottom line, on the right of screen, incorrect background color (690.72 KB, image/png)
2021-02-08 17:26 UTC, Nick
Details
Horizontal lines in Konsole, Fractional Scaling 1.5 (5.08 KB, image/png)
2023-02-23 20:25 UTC, nkwkelvin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lukebenes 2016-12-03 22:48:00 UTC
Created attachment 102604 [details]
Screenshot taken on KDE Neon

Steps to reproduce:
1. Displays -> Scale -> Scale Factor: 1.3
2. Restart
3. Open Konsole, type stuff

Expected Results:
Same as before scale

Actual Results:
Random horizontal lines appear and disappear. 

Different scale factors seem to make this better and worse, but I was able to reproduce this reliably in both KDE Neon and Arch with a 1.3 scale factor. Fonts don't seem to affect this as they use different system fonts. 

Verified in:
 KDE Neon Version 16.08.2 and 
 KDE Arch Version 16.08.3
Comment 1 lukebenes 2016-12-03 23:39:30 UTC
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.
Comment 2 d_p_leone 2016-12-06 04:02:55 UTC
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.
Comment 3 lukebenes 2016-12-19 05:23:23 UTC
Arch upgrade Konsole to Version 16.12.0
This issue has been resolved.
Comment 4 lukebenes 2016-12-19 20:36:13 UTC
Sorry, the problem still exists. It seems to takes longer to make the lines show up now.
Comment 5 Horst Schirmeier 2017-01-12 08:34:42 UTC
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).
Comment 6 Horst Schirmeier 2017-01-12 08:35:35 UTC
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.
Comment 7 Horst Schirmeier 2017-01-12 08:40:39 UTC
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.
Comment 8 Adam Dymitruk 2017-01-17 05:27:11 UTC
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).
Comment 9 Adam Dymitruk 2017-01-17 05:31:04 UTC
Created attachment 103452 [details]
after highlighting some text in the terminal

the line sometimes shows the backdrop image.
Comment 10 Christoph Feck 2017-02-08 02:09:27 UTC
*** Bug 376039 has been marked as a duplicate of this bug. ***
Comment 11 Gianguido Sorà 2017-02-09 16:42:32 UTC
On version 16.12.1, using Intel drivers with Xorg's modesetting, and glamor 2D acceleration, this behaviour doesn't appear anymore.
Comment 12 Ogi 2017-04-08 02:47:01 UTC
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).
Comment 13 Kurt Hindenburg 2017-04-18 02:31:45 UTC
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).
Comment 14 e.ekmecic 2017-04-21 14:13:23 UTC
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.
Comment 15 Lluís 2017-05-31 18:16:56 UTC
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/
Comment 16 Christoph Feck 2017-06-27 20:18:48 UTC
*** Bug 381646 has been marked as a duplicate of this bug. ***
Comment 17 CnZhx 2017-07-31 08:53:07 UTC
(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?
Comment 18 t123yh 2017-08-01 03:39:27 UTC
I found that these lines are actually transparent to the background (the window behind Konsole).
Comment 19 Lluís 2017-08-02 09:17:45 UTC
(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)
Comment 20 asem.arafa 2017-08-12 11:25:02 UTC
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
Comment 21 CnZhx 2017-08-15 10:57:59 UTC
(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 :)
Comment 22 Thomas 2017-08-15 20:13:58 UTC
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.
Comment 23 Stijn Tintel 2017-08-22 06:32:56 UTC
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.
Comment 24 Bruno Randolf 2017-09-19 22:00:10 UTC
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.
Comment 25 Christoph Feck 2017-10-25 19:32:32 UTC
*** Bug 385928 has been marked as a duplicate of this bug. ***
Comment 26 Nate Graham 2018-01-05 00:10:32 UTC
*** Bug 388539 has been marked as a duplicate of this bug. ***
Comment 27 bugreporter11 2018-01-05 00:20:29 UTC
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.
Comment 28 bugreporter11 2018-01-05 00:22:18 UTC
Created attachment 109683 [details]
Horizontal Lines in Kate on Arch Linux

These appear without doing anything out of the ordinary.
Comment 29 aerioeus 2018-02-04 08:43:45 UTC
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.
Comment 30 Lastique 2018-02-04 11:32:36 UTC
(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.
Comment 31 Nate Graham 2018-02-05 17:57:43 UTC
There's a patch undergoing review that aims to work around this issue: https://phabricator.kde.org/D10232
Comment 32 Clemens Eisserer 2018-02-19 22:34:32 UTC
+1
Comment 33 Florian Loitsch 2018-03-09 10:30:41 UTC
Afaics the patch is only for Konsole.
All other applications (Kate, Kdevelop, Okular?, ...) won't be fixed by that patch.
Comment 34 Nate Graham 2018-03-09 23:15:11 UTC
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.
Comment 35 Nate Graham 2018-07-13 16:09:36 UTC
*** Bug 396457 has been marked as a duplicate of this bug. ***
Comment 36 Nate Graham 2018-07-19 22:43:16 UTC
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?
Comment 37 Horst Schirmeier 2018-07-20 06:44:51 UTC
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.
Comment 38 Nate Graham 2018-07-20 13:19:35 UTC
I'm receiving multiple reports of the issue not being reproducible anymore. Calling this fixed, then!
Comment 39 bugreporter11 2018-07-21 08:09:32 UTC
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.
Comment 40 bugreporter11 2018-07-21 08:13:57 UTC
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.
Comment 41 bugreporter11 2018-07-21 08:18:34 UTC
My apologies for a 3rd comment. However, I forgot to add this important info:
konsole 18.04.3
Comment 42 Nate Graham 2018-07-21 20:27:34 UTC
We need a test with Konsole from git master, not 18.04.3
Comment 43 Sven Mauch 2018-07-23 13:38:54 UTC
I can still reproduce this issue in master.
Comment 44 Nate Graham 2018-07-23 14:35:41 UTC
Darn, thanks for testing.
Comment 45 lukebenes 2018-07-27 21:33:53 UTC
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.
Comment 46 Oskar 2018-08-01 16:30:22 UTC
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.
Comment 47 Bo Simonsen 2018-08-03 15:58:10 UTC
It seems only fixed for 1.5, other scalings e.g. 1.3 does still have the random lines.
Comment 48 Rolf Eichenseher 2018-08-11 06:39:16 UTC
(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.
Comment 49 Clemens Eisserer 2018-08-11 07:02:14 UTC
i am already couting days to the 2 year anniversary bug-report ;)
Comment 50 Kevin Wittek 2018-09-07 09:28:45 UTC
This is still happening for me with scale factor 1.5

KDE: 5.13.4
Konsole: 18.04.3
Fedora 28
Comment 51 Mark Jacobson 2018-09-08 00:14:30 UTC
I can confirm this bug is still present as well. 

Gentoo using 4.18.6 kernel
Konsole 18.04.3
Desktop is at 4k
Comment 52 Gennaro 2018-09-25 13:08:12 UTC
Still happening on Kubuntu 18.04 with fractional scale factors
Comment 53 bugreporter11 2018-09-25 18:37:09 UTC
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.
Comment 54 Nate Graham 2018-09-25 18:42:56 UTC
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!
Comment 55 Patrick Silva 2018-09-25 18:47:31 UTC
(In reply to bugreporter11 from comment #53)
> Is there a similar bug
> report open for Kate? Kate has these horizontal lines too.

bug 390451
Comment 56 Clemens Eisserer 2018-09-25 18:48:11 UTC
> 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.
Comment 57 Nate Graham 2018-09-25 19:00:44 UTC
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. :)
Comment 58 Dominik Haumann 2018-09-25 19:18:49 UTC
*** Bug 399072 has been marked as a duplicate of this bug. ***
Comment 59 Nate Graham 2018-10-20 23:49:54 UTC
*** Bug 350651 has been marked as a duplicate of this bug. ***
Comment 60 Patrick Silva 2018-10-21 01:32:48 UTC
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?
Comment 61 Nate Graham 2018-10-21 18:40:23 UTC
NooOooOOOOooooooooooo... :(
Comment 62 Christoph Cullmann 2018-10-22 05:28:26 UTC
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.
Comment 63 Nate Graham 2018-10-22 23:51:46 UTC
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).
Comment 64 Vavooon 2018-10-24 13:21:33 UTC
I can confirm that on latest 5.12 beta this issue still appears for me in both Kate and Yakuake.
Comment 65 Tomasz Rychter 2018-11-01 20:27:12 UTC
Kubuntu 18.04.1 - Konsole Version 17.12.3 - bug still exists
(gnome-terminal works just fine)
Comment 66 Alexander Miroshnichenko 2018-11-14 07:04:34 UTC
Same issue.

kde-frameworks: 5.50.0
Konsole, kate: 18.04.3
Qt: 5.11.1
Scale factor: 1.5
Font dpi: 144
Comment 67 Benjamin Buch 2018-12-12 21:48:18 UTC
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)
Comment 68 4k1r4.rulez 2018-12-15 06:35:40 UTC
Qt 5.12
Konsole 18.12.0

The issue still exists
Comment 69 HM 2018-12-16 17:55:18 UTC
Issue still there in Konsole, Yakuake,Kate
Plasma version 5.14.4
Scaling at 1.4
Linux 4.19
Comment 70 Christoph Feck 2018-12-17 02:08:49 UTC
There is no need to state it multiple times. If the issue gets fixed, the bug gets closed.
Comment 71 Clemens Eisserer 2018-12-19 11:14:01 UTC
> 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.
Comment 72 4k1r4.rulez 2018-12-19 11:28:01 UTC
(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 .
Comment 73 Nate Graham 2018-12-19 14:57:51 UTC
(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.
Comment 74 Bo Simonsen 2019-01-26 10:41:08 UTC
With Applications/18.12 commit 807ac77061604c2ac7cf84b0a0b29dd949a6c634 makes it even worse, for e.g. "mc". Not sure if it should be a seperate bug report?
Comment 75 Wolfgang Bauer 2019-01-27 01:53:07 UTC
(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).
Comment 76 Christoph Feck 2019-02-08 15:51:35 UTC
*** Bug 403251 has been marked as a duplicate of this bug. ***
Comment 77 Christoph Feck 2019-02-22 16:09:28 UTC
*** Bug 403911 has been marked as a duplicate of this bug. ***
Comment 78 Bo Simonsen 2019-04-22 15:05:05 UTC
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.
Comment 79 Bo Simonsen 2019-04-27 20:14:14 UTC
Can anybody verify the lines go away if konsole is started with --notransparency?
Comment 80 Sven Mauch 2019-04-27 20:25:12 UTC
(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. :)
Comment 81 Harry ten Berge 2019-04-27 20:27:57 UTC
Yes, confirmed that with '--notransparency' the artifacts are gone.
Comment 82 Bo Simonsen 2019-04-28 08:24:20 UTC
(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.
Comment 83 Philipp Verpoort 2019-04-28 10:24:33 UTC
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.
Comment 84 Lastique 2019-05-28 22:03:56 UTC
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.
Comment 85 Lastique 2019-05-28 22:10:38 UTC
Created attachment 120365 [details]
Konsole with Midnight Commander correct

For reference, this is how it should look.
Comment 86 Christoph Feck 2019-05-31 14:43:10 UTC
Which Konsole version is comment #85? I thought we fixed line graphics already.
Comment 87 Lastique 2019-05-31 15:32:52 UTC
This is on Kubuntu 19.04.
Konsole: 18.12.3
KDE Plasma: 5.15.4
KDE Frameworks: 5.56.0
Qt: 5.12.2
Comment 88 Christoph Feck 2019-05-31 15:53:45 UTC
Please test Konsole 19.04, see bug 402415. I am unsure if anyone tested line graphics using fractional scaling.
Comment 89 Nate Graham 2019-05-31 15:56:11 UTC
Can reproduce using Konsole 19.04 as well as from git master.
Comment 90 Nate Graham 2019-05-31 16:01:26 UTC
Looks like that issue is tracked by Bug 406770.
Comment 91 Jeffrey Bouter 2019-05-31 16:19:03 UTC
(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)
Comment 92 Lastique 2019-05-31 16:54:28 UTC
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.
Comment 93 Jeffrey Bouter 2019-05-31 18:13:41 UTC
Created attachment 120456 [details]
konsole_photo_prompt_return
Comment 94 Jeffrey Bouter 2019-05-31 18:15:07 UTC
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.
Comment 95 postix 2019-05-31 18:19:05 UTC
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)
Comment 96 Wolfgang Bauer 2019-05-31 19:05:17 UTC
(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.
Comment 97 Jeffrey Bouter 2019-05-31 19:46:41 UTC
Created attachment 120461 [details]
Konsole Select Text

There's no need to launch Midnight Commander, just selecting multiple lines will suffice.
Comment 98 Fabian Lesniak 2019-06-01 23:32:57 UTC
(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.
Comment 99 Wolfgang Bauer 2019-06-02 08:44:06 UTC
(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.
Comment 100 Nicolas 2019-06-02 09:16:19 UTC
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
Comment 101 Wolfgang Bauer 2019-06-02 10:16:38 UTC
(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.
Comment 102 Wolfgang Bauer 2019-06-02 10:22:50 UTC
(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.
Comment 103 postix 2019-06-02 10:41:34 UTC
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
Comment 104 postix 2019-06-02 10:42:38 UTC
Created attachment 120496 [details]
Horizontal lines in Konsole; Fractional Scaling 1.5; Transparency=True
Comment 105 Robbert van der Helm 2019-06-09 21:54:26 UTC
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
Comment 106 postix 2019-06-13 19:29:00 UTC
(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! :-)
Comment 107 genbushi 2019-06-28 11:42:46 UTC
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
Comment 108 Rober 2019-06-28 16:15:03 UTC
(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
Comment 109 lukebenes 2019-08-15 15:58:00 UTC
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?
Comment 110 rjurado 2019-09-26 16:33:27 UTC
(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 !!
Comment 111 Christoph Cullmann 2019-10-01 20:18:21 UTC
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...
Comment 112 Christoph Cullmann 2019-10-02 20:54:33 UTC
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.
Comment 113 Christoph Cullmann 2019-10-02 20:56:22 UTC
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
Comment 114 Christoph Cullmann 2019-10-02 20:56:27 UTC
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
Comment 115 Christoph Cullmann 2019-10-02 20:59:17 UTC
Created attachment 122981 [details]
pre patch with QT_SCALE_FACTOR=1.5
Comment 116 Christoph Cullmann 2019-10-02 20:59:42 UTC
Created attachment 122982 [details]
post patch with QT_SCALE_FACTOR=1.5
Comment 117 Christoph Cullmann 2019-10-02 21:31:40 UTC
*** Bug 406770 has been marked as a duplicate of this bug. ***
Comment 118 Christoph Cullmann 2019-10-02 22:00:30 UTC
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...
Comment 119 Christoph Cullmann 2019-10-02 22:12:09 UTC
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)
Comment 120 Christoph Cullmann 2019-10-02 22:22:51 UTC
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 ;)
Comment 121 Christoph Cullmann 2019-10-02 22:44:11 UTC
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
Comment 122 Christoph Cullmann 2019-10-02 22:44:16 UTC
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
Comment 123 Christoph Cullmann 2019-10-02 23:21:43 UTC
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 :/
Comment 124 Christoph Cullmann 2019-10-03 00:28:26 UTC
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?
Comment 125 Christoph Cullmann 2019-10-03 00:33:42 UTC
fillRect bug with anti-aliasing reported here 

https://bugreports.qt.io/browse/QTBUG-78964
Comment 126 Christoph Cullmann 2019-10-03 14:47:16 UTC
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?
Comment 127 Christoph Cullmann 2019-10-03 19:44:33 UTC
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
Comment 128 Christoph Cullmann 2019-10-03 19:44:33 UTC
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
Comment 129 Christoph Cullmann 2019-10-03 19:44:37 UTC
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
Comment 130 Christoph Cullmann 2019-10-03 19:56:49 UTC
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...
Comment 131 Ahmad Samir 2019-10-03 21:28:28 UTC
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.
Comment 132 Christoph Cullmann 2019-10-03 21:35:35 UTC
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.
Comment 133 Christoph Cullmann 2019-10-03 21:40:40 UTC
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
Comment 134 Christoph Cullmann 2019-10-03 21:40:45 UTC
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
Comment 135 Christoph Cullmann 2019-10-03 21:41:35 UTC
Hmpf, most of our applications still miss that flag and look strange in non-plasma desktop settings :/
Comment 136 Christoph Cullmann 2019-10-04 18:26:22 UTC
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
Comment 137 Christoph Cullmann 2019-10-04 18:26:27 UTC
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
Comment 138 Patrick Silva 2019-10-15 12:30:46 UTC
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.
Comment 139 Christoph Cullmann 2019-10-15 18:34:37 UTC
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.
Comment 140 Nate Graham 2019-10-16 14:50:08 UTC
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
Comment 141 Francesco Esposito 2019-11-16 19:08:48 UTC
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
Comment 142 lukebenes 2019-11-17 18:13:51 UTC
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.
Comment 143 undying.k 2019-11-19 20:03:30 UTC
(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
Comment 144 rjurado 2019-11-20 19:35:25 UTC
I have:

 - KDE Plasma 5.17.3
 - Global scale factor: 1.1k

And bug is still remains.
Comment 145 Mantas Mikalauskas 2019-11-22 19:19:31 UTC
Bug is still remains with scale factor of 1.3
Comment 146 genbushi 2019-11-24 15:05:12 UTC
Created attachment 124101 [details]
konsole menu artifacts and lines
Comment 147 genbushi 2019-11-24 15:08:51 UTC
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 148 genbushi 2019-11-24 15:11:16 UTC
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
Comment 149 lukebenes 2019-12-02 13:56:54 UTC
(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/
Comment 150 Arthur Peters 2019-12-02 14:42:26 UTC
(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.
Comment 151 Nate Graham 2019-12-02 21:07:13 UTC
*** Bug 414752 has been marked as a duplicate of this bug. ***
Comment 152 Andrew 2019-12-06 14:14:45 UTC
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.
Comment 153 postix 2019-12-06 14:37:09 UTC
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.
Comment 154 postix 2019-12-06 14:59:58 UTC
> > 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.
Comment 155 Andrew 2019-12-07 02:00:28 UTC
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.
Comment 156 Ahmad Samir 2019-12-07 06:39:23 UTC
(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.
Comment 157 Arthur Peters 2019-12-07 20:15:37 UTC
(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).
Comment 158 Lastique 2019-12-07 23:08:34 UTC
(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.
Comment 159 Peter Hatina 2019-12-08 10:52:50 UTC
(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.
Comment 160 Christoph Cullmann 2019-12-08 15:08:15 UTC
> 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.
Comment 161 Peter Hatina 2019-12-08 15:44:44 UTC
(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?
Comment 162 lukebenes 2019-12-12 16:06:58 UTC
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.
Comment 163 Bernie Innocenti 2019-12-14 21:19:43 UTC
(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 :-(
Comment 164 Ahmad Samir 2019-12-16 12:00:12 UTC
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.
Comment 165 postix 2020-01-02 18:04:36 UTC
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. :-)
Comment 166 Giusy Digital 2020-01-08 11:02:24 UTC
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
Comment 167 Potomac 2020-01-10 10:32:10 UTC
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.
Comment 168 Potomac 2020-01-10 12:18:59 UTC
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
Comment 169 Potomac 2020-01-10 12:34:20 UTC
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).
Comment 170 Christoph Feck 2020-01-10 16:41:49 UTC
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.
Comment 171 Potomac 2020-01-10 20:57:24 UTC
(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
Comment 172 Wolfgang Bauer 2020-01-11 13:29:27 UTC
(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
Comment 173 Wolfgang Bauer 2020-01-11 13:33:56 UTC
(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.
Comment 174 Wolfgang Bauer 2020-01-11 13:37:43 UTC
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.
Comment 175 Wolfgang Bauer 2020-01-11 14:11:21 UTC
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...
Comment 176 tuor 2020-01-20 10:58:36 UTC
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
Comment 177 postix 2020-01-20 11:44:12 UTC
(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
Comment 178 Patrick Silva 2020-02-11 15:57:39 UTC
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
Comment 179 Lucas Pires Camargo 2020-02-13 23:23:05 UTC
(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.
Comment 180 Christoph Cullmann 2020-02-14 05:56:22 UTC
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...)
Comment 181 Lucas Pires Camargo 2020-02-14 15:22:30 UTC
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.
Comment 182 Lucas Pires Camargo 2020-02-14 15:24:33 UTC
(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.
Comment 183 lukebenes 2020-02-14 16:30:45 UTC
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?
Comment 184 Lucas Pires Camargo 2020-02-14 17:03:40 UTC
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.
Comment 185 Lastique 2020-02-14 19:38:57 UTC
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?
Comment 186 Lucas Pires Camargo 2020-02-17 13:07:11 UTC
(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
Comment 187 Lucas Pires Camargo 2020-02-17 13:12:13 UTC
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.
Comment 188 Patrick Silva 2020-04-13 17:21:13 UTC
*** Bug 420042 has been marked as a duplicate of this bug. ***
Comment 189 Nate Graham 2020-04-15 03:25:34 UTC
*** Bug 419910 has been marked as a duplicate of this bug. ***
Comment 190 Clemens Eisserer 2020-04-21 08:33:10 UTC
even worse - with F31 + latest updates I get not only horizontal lines but blinking / missing text. it makes konsole almost unuseable.
Comment 191 Roberth Sjonøy 2020-04-21 08:36:16 UTC
https://bugreports.qt.io/browse/QTBUG-82601

The patch attached there fixed the issue for me.
Comment 192 Patrick Silva 2020-04-22 01:09:00 UTC
*** Bug 420394 has been marked as a duplicate of this bug. ***
Comment 193 Andrés Cabero 2020-05-04 08:26:42 UTC
(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.
Comment 194 Patrick Silva 2020-05-10 18:29:23 UTC
*** Bug 421285 has been marked as a duplicate of this bug. ***
Comment 195 Nate Graham 2020-05-15 15:35:27 UTC
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?
Comment 196 Patrick Silva 2020-05-15 15:46:20 UTC
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
Comment 197 Joe 2020-05-15 20:29:31 UTC
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
Comment 198 Christoph Feck 2020-05-18 00:52:26 UTC
*** Bug 421692 has been marked as a duplicate of this bug. ***
Comment 199 Christoph Feck 2020-06-13 00:40:29 UTC
*** Bug 422220 has been marked as a duplicate of this bug. ***
Comment 200 Ryein Goddard 2020-06-14 17:32:25 UTC
KDE Neon with Qt 5.14.2.

Konsole is giving me these random lines at 175% scale factor.
Comment 201 Ruth Ivimey-Cook 2020-06-23 22:33:00 UTC
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?
Comment 202 Andrei Ivnitskii 2020-07-01 09:40:18 UTC
Confirm. Ubuntu 20.04, global scale 125%
Comment 203 Vlad Zahorodnii 2020-07-01 12:42:59 UTC
*** Bug 423733 has been marked as a duplicate of this bug. ***
Comment 204 Germano Massullo 2020-07-04 14:07:28 UTC
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
Comment 205 Nate Graham 2020-07-09 19:18:00 UTC
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.
Comment 206 Jan Kalmar 2020-07-12 11:07:56 UTC
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
Comment 207 popov895 2020-07-16 15:29:44 UTC
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
Comment 208 Jan Kalmar 2020-07-16 15:43:40 UTC
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.
Comment 209 popov895 2020-07-19 10:14:55 UTC
Created attachment 130234 [details]
Search field in the System Settings with 125% DPI scale
Comment 210 Patrick Silva 2020-07-19 15:40:03 UTC
*** Bug 424412 has been marked as a duplicate of this bug. ***
Comment 211 dontdieych 2020-07-25 00:13:21 UTC
(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.
Comment 212 dontdieych 2020-07-25 00:14:29 UTC
(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
Comment 213 Ruth Ivimey-Cook 2020-08-16 11:59:41 UTC
Created attachment 130908 [details]
Patchfile of debugging code intended to assist finding terminal display bugs.
Comment 214 Ruth Ivimey-Cook 2020-08-16 12:00:12 UTC
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.
Comment 215 Christoph Cullmann 2020-08-16 12:16:04 UTC
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.
Comment 216 Ruth Ivimey-Cook 2020-08-16 18:54:12 UTC
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
Comment 217 Ryan 2020-10-14 07:38:38 UTC
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.
Comment 218 Ruth Ivimey-Cook 2020-10-14 16:09:00 UTC
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.
Comment 219 Patrick Silva 2020-10-16 01:55:21 UTC
*** Bug 427781 has been marked as a duplicate of this bug. ***
Comment 220 bugreporter11 2020-10-16 17:09:02 UTC
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.
Comment 221 PK 2020-10-23 07:50:58 UTC
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.
Comment 222 Roman Mikula 2020-10-28 19:56:48 UTC
Created attachment 132847 [details]
Horizontal lines with fractional HiDPI scaling
Comment 223 ykla 2020-11-05 13:48:39 UTC
This bug still in FreeBSD 12.2.
KDE 5.75.0
QT 5.15.0
Konsole 20.08.2
Comment 224 PK 2020-11-05 13:55:59 UTC
And, Ykla, what happens if you set scene scaling to 100 %? Just out of curiositeit...
Comment 225 PK 2020-11-05 13:57:53 UTC
I Ment "screen scaling" in the precious comment...
Comment 226 Germano Massullo 2020-11-05 14:12:03 UTC
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
Comment 227 Ryein Goddard 2020-11-05 14:33:54 UTC
I have the same version and still experiencing the issue.  Fresh reboot.

175% scaling on 4k monitor.
Comment 228 Ryein Goddard 2020-11-05 14:34:58 UTC
(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?
Comment 229 ykla 2020-11-06 02:50:20 UTC
PK,set 100% is normal, no horizontal lines.
Comment 230 Aru Sahni 2020-11-06 02:57:33 UTC
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.
Comment 231 postix 2020-11-06 11:19:21 UTC
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.
Comment 232 popov895 2020-11-12 16:13:01 UTC
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.
Comment 233 Ryein Goddard 2020-11-12 16:14:38 UTC
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.
Comment 234 Christoph Feck 2020-11-12 16:24:12 UTC
Qt 5.15.1 fixed it, confirmed by several reporters; closing.

> problems with vertical lines

Bug 425408?
Comment 235 Christoph Cullmann 2020-11-12 17:05:09 UTC
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.
Comment 236 Patrick Silva 2020-11-15 16:00:24 UTC
*** Bug 428898 has been marked as a duplicate of this bug. ***
Comment 237 andrew 2020-11-15 20:35:14 UTC
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.
Comment 238 postix 2020-11-15 21:00:09 UTC
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.)
Comment 239 andrew 2020-11-16 13:26:21 UTC
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.
Comment 240 Christoph Feck 2020-11-16 13:31:53 UTC
This issue was fixed in Qt 5.15.1.
Comment 241 andrew 2020-11-16 13:45:16 UTC
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.
Comment 242 Nick 2021-02-08 12:44:18 UTC
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.
Comment 243 Nick 2021-02-08 16:57:40 UTC
(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.
Comment 244 Nick 2021-02-08 17:20:44 UTC
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.
Comment 245 Nick 2021-02-08 17:26:20 UTC
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.
Comment 246 Nate Graham 2021-02-08 19:50:48 UTC
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!
Comment 247 Nick 2021-02-08 20:14:43 UTC
(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.
Comment 248 Nick 2021-02-08 22:13:17 UTC
(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
Comment 249 nkwkelvin 2023-02-23 20:25:32 UTC Comment hidden (spam)
Comment 250 Nate Graham 2023-02-23 22:48:04 UTC Comment hidden (spam)
Comment 251 nkwkelvin 2023-02-24 00:07:42 UTC
(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!
Comment 252 Joe 2023-03-01 03:03:59 UTC
I still get horizontal lines (again) in Konsole on 5.27.2 on Wayland w/ fractional scaling. Should I open a new bug report?
Comment 253 Nate Graham 2023-03-01 15:09:34 UTC
It's most likely Bug 465158.
Comment 254 nkwkelvin 2023-03-01 15:35:48 UTC
(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.
Comment 255 Nate Graham 2023-03-01 15:56:16 UTC
Then perhaps it isn't that. Please submit a new bug report for it. Thanks!
Comment 256 Denis 2023-04-23 11:06:34 UTC
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").
Comment 257 Luca Carlon 2023-04-23 16:08:59 UTC
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.
Comment 258 Luca Carlon 2023-04-24 12:48:23 UTC
This is another related patch for the underline: https://invent.kde.org/utilities/konsole/-/merge_requests/843.
Comment 259 Matan Ziv-Av 2023-04-27 07:28:15 UTC
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
Comment 260 Luca Carlon 2023-05-12 20:47:23 UTC
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