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.
Created attachment 165132 [details] Phone pic -- shows the issue
Cannot reproduce at 250% or 175% scale. Seems to only happen at 225% scale.
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?
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.
Okay. Next I'll need the exact sizes for the panel and both windows, as shown by the debug console as "bufferGeometry".
BufferGeometry values: - Left screen edge panel: -16,0 66x960 - Left-tiled Firefox: 50,28 802x932 - Right-tiled Konsole: 854,28 852x932
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.
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?
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.
Darn.
*** Bug 481125 has been marked as a duplicate of this bug. ***
*** Bug 481197 has been marked as a duplicate of this bug. ***
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?
*** Bug 482351 has been marked as a duplicate of this bug. ***
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.
(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
*** Bug 483198 has been marked as a duplicate of this bug. ***
*** Bug 483152 has been marked as a duplicate of this bug. ***
*** Bug 485872 has been marked as a duplicate of this bug. ***
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.
(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
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.
Created attachment 168756 [details] glitch visible at 125%
Created attachment 168757 [details] no glitch at 130%
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.
(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.
(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.
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?