Bug 480171 - Right-side-tiled windows and full-screen video/image content are not fully adjacent to right screen edge when using certain fractional scale factors
Summary: Right-side-tiled windows and full-screen video/image content are not fully ad...
Status: ASSIGNED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: master
Platform: Other Linux
: HI normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 481197 482351 483152 485872 487726 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-01-22 15:22 UTC by Nate Graham
Modified: 2024-06-08 14:35 UTC (History)
24 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screenshot - does not show the issue (373.73 KB, image/jpeg)
2024-01-22 15:22 UTC, Nate Graham
Details
Phone pic -- shows the issue (2.07 MB, image/jpeg)
2024-01-22 15:23 UTC, Nate Graham
Details
Full-screen screenshot (1.03 MB, image/jpeg)
2024-02-05 20:05 UTC, Nate Graham
Details
glitch visible at 125% (473.61 KB, image/png)
2024-04-21 18:25 UTC, Andrea Ippolito
Details
no glitch at 130% (302.62 KB, image/png)
2024-04-21 18:25 UTC, Andrea Ippolito
Details
Issue visible on internal monitor of dell latitude 9330 (127.79 KB, image/png)
2024-06-02 10:33 UTC, Xwang
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2024-01-22 15:22:55 UTC
Created attachment 165131 [details]
Screenshot - does not show the issue

Plasma 6 Wayland with today's git master. 4K laptop screen, 225% scale, standard fonts.


STEPS TO REPRODUCE 1
1. Set scale factor to 225% on a 4K screen
2. Tile a window to the right side

OBSERVED RESULT 1
The window is not fully adjacent to the right screen edge such that Fitts' Law is broken for its UI controls; I cannot activate its scrollbar or close button by flinging my pointer into the right edge or corner and clicking


STEPS TO REPRODUCE 2
1. Set scale factor to 225% on a 4K screen
2. Play a video full screen on YouTube, or in DragonPlayer. Or do a full-screen slideshow in Gwenview

OBSERVED RESULT 2
There is a distracting line of pixels on the right side


ADDITIONAL INFORMATION
The issue does not show up in a screenshot, so it seems like KWin thinks it's doing the right thing here--but it's not.

Does not reproduce in Kate or Firefox's full screen modes that are invoked by hitting the F11 key.
Comment 1 Nate Graham 2024-01-22 15:23:52 UTC
Created attachment 165132 [details]
Phone pic -- shows the issue
Comment 2 Nate Graham 2024-01-22 15:33:44 UTC
Cannot reproduce at 250% or 175% scale. Seems to only happen at 225% scale.
Comment 3 Zamundaaa 2024-02-01 19:51:18 UTC
Can you check the exact size of the screenshot / whether or not it matches the screen or if the line is just not visible on it because the rightmost pixel is cut off from the image?
Comment 4 Nate Graham 2024-02-05 20:05:26 UTC
Created attachment 165579 [details]
Full-screen screenshot

A full-screen screenshot shows the line; see attached. The Konsole window is tiled to the right, but if you look at the top-right corner of the screenshot, you can see a line of yellow pixels from the wallpaper bleeding through.
Comment 5 Zamundaaa 2024-02-08 21:56:53 UTC
Okay. Next I'll need the exact sizes for the panel and both windows, as shown by the debug console as "bufferGeometry".
Comment 6 Nate Graham 2024-02-08 22:03:13 UTC
BufferGeometry values:
- Left screen edge panel: -16,0 66x960
- Left-tiled Firefox: 50,28 802x932
- Right-tiled Konsole: 854,28 852x932
Comment 7 Zamundaaa 2024-02-08 22:27:31 UTC
Yeah, that can't work. round(854 * 2.25) + round(852 * 2.25) = 3839... There's simply a pixel missing, and because both layouting logic in KWin and fractional-scale-v1 are in integer logical coordinates, there is no way to add only one pixel.
Comment 8 Nate Graham 2024-02-13 01:47:56 UTC
Can't we add a pixel after the floating point scaling happens? If KWin knows that the panel plus two tiled windows is 3839, and the screen's physical pixel width is 3840, then at some point KWin can tell that a pixel is missing. Can we add a pixel of width during the process of tiling itself, after KWin has calculated the physical size of the tiled window?
Comment 9 Zamundaaa 2024-02-13 16:07:22 UTC
The way that fractional-scale-v1 works means that you cannot add only one pixel with that scale+size combination, we could only add two. This needs Wayland protocols and Qt changes to be fixable.
Comment 10 Nate Graham 2024-02-13 17:27:25 UTC
Darn.
Comment 11 Nate Graham 2024-02-15 02:44:50 UTC
*** Bug 481125 has been marked as a duplicate of this bug. ***
Comment 12 Nate Graham 2024-02-21 20:14:51 UTC
*** Bug 481197 has been marked as a duplicate of this bug. ***
Comment 13 gudvinr+kde 2024-02-29 15:24:59 UTC
Can you really "fix" protocol though?

fractional-scale-v1 uses 120 as denominator, which limits amount of scale factors you can use to get integer window sizes. 2.25 gives 270/120, which makes "virtual" screen size 1706.(6) for 3840.
Closest integer scale sizes are 256/120 and 288/120 which will give 1800 and 1600 "virtual" screens, respectively.

Wouldn't that be easier to just limit values for scale factors, so you won't get into situation where kwin needs to make things up?
Comment 14 fanzhuyifan 2024-03-04 03:06:31 UTC
*** Bug 482351 has been marked as a duplicate of this bug. ***
Comment 15 Zamundaaa 2024-03-04 14:47:11 UTC
The protocol can't be fixed, but it can very much be replaced with a better solution.

> Wouldn't that be easier to just limit values for scale factors, so you won't get into situation where kwin needs to make things up?
You can do that for one dimension or with two, if the sizes happen to match up nicely. But when you have a slightly more complex system, it falls apart very quickly. "More complex" means "default" here - with a panel on the bottom, you got at least 6 trivially visible sizes that the scale needs to work for:
- the panel height
- the height of maximized windows
- the height of fullscreen windows
- the width of the screen
- the width of a left-tiled window
- the width of a right-tiled window

Users can also drag tile splits around arbitrarily, split the screen into three tiles, resize windows arbitrarily, have adjustable gaps between tiles... There's no realistic way to match a scale to all of these all at once.
Comment 16 gudvinr+kde 2024-03-06 12:39:10 UTC
(In reply to Zamundaaa from comment #15)
> > Wouldn't that be easier to just limit values for scale factors, so you won't get into situation where kwin needs to make things up?
> You can do that for one dimension or with two, if the sizes happen to match
> up nicely. But when you have a slightly more complex system, it falls apart
> very quickly.

Sure, I can agree after thinking a bit more about that.

(In reply to Zamundaaa from comment #15)
> The protocol can't be fixed, but it can very much be replaced with a better
> solution.

As far as I know, there's no better solution being considered or proposed for the time being.

I see 2 major issues with any potential solutions that don't solve this issue for arbitrary scale factor on arbitrary screen:
- With any fixed point scale value problem is just getting shifted to other scale values. You probably can get denominator big enough so it wouldn't matter for today's screen resolutions but I am not sure if it's possible to make it future proof.
- With floating point values you might get sporadic missing pixels due to errors during FP add/sub/mul/etc. Also at some point decision needs to be made because pixels are discrete, so client and server might not agree on what is correct rounding direction is, etc, etc
Comment 17 Nate Graham 2024-03-11 20:23:42 UTC
*** Bug 483198 has been marked as a duplicate of this bug. ***
Comment 18 Nate Graham 2024-03-11 21:24:51 UTC
*** Bug 483152 has been marked as a duplicate of this bug. ***
Comment 19 fanzhuyifan 2024-04-21 16:32:25 UTC
*** Bug 485872 has been marked as a duplicate of this bug. ***
Comment 20 Andrea Ippolito 2024-04-21 18:12:44 UTC
I wonder if I belong here...

https://community.frame.work/t/weird-1px-vertical-line-at-the-right-border/49402

In my case however it doesn't look as night-and-day as in Nate's phone pic, your line of pixels looks white, mine is very varied, and it doesn't even reflect the colors of the wallpaper underneath.

I'm not sure if I'm seeing this issue, or yet another one.
Comment 21 Andrea Ippolito 2024-04-21 18:14:25 UTC
(In reply to Andrea Ippolito from comment #20)
> I wonder if I belong here...
> 
> https://community.frame.work/t/weird-1px-vertical-line-at-the-right-border/
> 49402
> 
> In my case however it doesn't look as night-and-day as in Nate's phone pic,
> your line of pixels looks white, mine is very varied, and it doesn't even
> reflect the colors of the wallpaper underneath.
> 
> I'm not sure if I'm seeing this issue, or yet another one.

Oh, and sorry I forgot to mention: happens at 125% (Wayland session) and disappears instantly as soon as I go 100%.

I'm using a Framework 13 laptop, native resolution is 2256x1504.

System info:

Operating System: openSUSE Tumbleweed 20240419
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0
Kernel Version: 6.8.7-1-default (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840U w/ Radeon 780M Graphics
Memory: 30,7 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: Framework
Product Name: Laptop 13 (AMD Ryzen 7040Series)
System Version: A7
Comment 22 Andrea Ippolito 2024-04-21 18:25:01 UTC
Did some testing looking for glitches in the rightmost column of pixels, here are my findings:

100 OK
105 ko
110 ko
115 ko
120 OK
125 ko
130 OK
135 OK
140 ko
145 ko
150 OK
155 ko
160 OK
165 OK
170 OK
175 OK
180 ko
185 ko
190 ko
195 ko
200 OK
225 ko

Interestingly, my glitch DOES appear in a screenshot (visible at 125%, but disappears at 130%). Refer to attachments.
Comment 23 Andrea Ippolito 2024-04-21 18:25:25 UTC
Created attachment 168756 [details]
glitch visible at 125%
Comment 24 Andrea Ippolito 2024-04-21 18:25:39 UTC
Created attachment 168757 [details]
no glitch at 130%
Comment 25 mmc 2024-04-28 12:26:50 UTC
I have a monitor with a resolution of 2560 x 1440. When I use Plasma 6 with 150% scaling, I see the distracting line on the right side of the screen. On Plasma 5.27, there was no line but some applications and games would report the maximum resolution as 2561x1440. I did have to lower the game resolution to 2560x1440 as it did cause some graphical issues within the game. Now on Plasma 6, every game I have tested reports a maximum of 2560 x 1440 and works normally. But the line is present everywhere.

One thing I tried was installing the colour profile for my monitor, provided by the manufacturer. The line does disappear when using the profile. Though I think it may only be hiding the issue.
Comment 26 Denis Shiga 2024-04-28 12:41:11 UTC
(In reply to mmc from comment #25)
> I have a monitor with a resolution of 2560 x 1440. When I use Plasma 6 with
> 150% scaling, I see the distracting line on the right side of the screen. On
> Plasma 5.27, there was no line but some applications and games would report
> the maximum resolution as 2561x1440. I did have to lower the game resolution
> to 2560x1440 as it did cause some graphical issues within the game. Now on
> Plasma 6, every game I have tested reports a maximum of 2560 x 1440 and
> works normally. But the line is present everywhere.

Your behavior on Plasma 5.27 can be confirmed here https://bugs.kde.org/show_bug.cgi?id=481125 
Is was said that it was fixed in Plasma 6. I haven't checked yet but now I have my doubts.
Comment 27 mmc 2024-04-28 12:58:00 UTC
(In reply to Denis Shiga from comment #26)
> Your behavior on Plasma 5.27 can be confirmed here
> https://bugs.kde.org/show_bug.cgi?id=481125 
> Is was said that it was fixed in Plasma 6. I haven't checked yet but now I
> have my doubts.

Yes, I think that particular bug has been fixed in Plasma 6 as I no longer see 2561x1440 being reported by the games running in XWayland, when using 150% scaling.

Forgot to mention that I am running Wayland.
Comment 28 Eamonn Rea 2024-05-02 00:17:02 UTC
I see mention that this issue is a result of the fractional-scaling-v1 protocol and integer coordinates. Could the fractional-scale-v2 fix this in its current state (https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/149), since I believe it allows for floating-point coordinates and sizes (at least according to the wlroots PR: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3809).

Or would this need to be either a rework of the fractional-scale-v2 protocol, a fractional-scale-v3 protocol, or something else?

It sounds like the fractional-scale-v2 protocol would fix many issues people are having with v1. I realise there are many more hurdles than simply saying "Yes this may solve it", because this protocol is not yet implemented and may need some work on the toolkit side and so on.

But, I guess what I'm wondering is, in a best case, could this issue and other issues people are facing with fractional-scaling be resolved with the current implementation of fractional-scale-v2?
Comment 29 Zamundaaa 2024-05-12 10:41:02 UTC
Yes, fractional-scale-v2 should fix this, but we don't have a Qt implementation yet to actually test it in practice
Comment 30 David Redondo 2024-05-29 07:11:17 UTC
*** Bug 487726 has been marked as a duplicate of this bug. ***
Comment 31 Xwang 2024-06-02 10:33:24 UTC
Created attachment 170061 [details]
Issue visible on internal monitor of dell latitude 9330

As you can see from the attached images, I feel I'm facing the same (or at least similar issue), but I'm not sure because the internal screen is 2560x1600, it uses 160% scale and the panel is 64px.
So dividing the sizes by 1.6, the pixel number is integer both for the whole screen, and the panel and Konsole areas. Once I remove the height of the panel, the Konsole window measures (2560x1536) which divided by 1.6 gives an integer 1600x960 once the scaling is applied. 
The panel itself measures (2560x64) which give a scaled dimension of 1600x40 once scaling is applied.
So I do not understand why I still see the issue.
Is there anything else I should consider?

My system is the following:
Operating System: Arch Linux 
KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1
Kernel Version: 6.9.3-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × 12th Gen Intel® Core™ i5-1240U
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: Dell Inc.
Product Name: Latitude 9330
Comment 32 Nate Graham 2024-06-07 21:49:52 UTC
*** Bug 459373 has been marked as a duplicate of this bug. ***
Comment 33 Nate Graham 2024-06-07 21:51:04 UTC

*** This bug has been marked as a duplicate of bug 459373 ***
Comment 34 Nate Graham 2024-06-07 23:04:08 UTC
Xaver set me right; this is in fact a different issue that needs a different fix—that fix being  https://invent.kde.org/plasma/kwin/-/merge_requests/3170, which can go in after the required protocol changes are implemented upstream.