Bug 399280 - Vertical pixel gap at right screen edge after maximizing a window when using certain fractional scale factors
Summary: Vertical pixel gap at right screen edge after maximizing a window when using ...
Status: RESOLVED DUPLICATE of bug 391956
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.12.6
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-10-01 14:32 UTC by lizhujin
Modified: 2018-10-04 17:12 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
kde: Wayland-
kde: X11+


Attachments
screenshot (135.13 KB, image/png)
2018-10-01 14:32 UTC, lizhujin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lizhujin 2018-10-01 14:32:46 UTC
Created attachment 115344 [details]
screenshot

SUMMARY
There is a pixel gap at the right edge of the screen after maximizing a window. It gets annoying especially when I'm playing videos in full screen mode (VLC). And I find it concerned with DPI scaling factor.

STEPS TO REPRODUCE
1. Set scaling factor to 1.4 in 'Display and Monitor'.
2. Open Dolphin (or any other built-in apps) and maximize the window.

OBSERVED RESULT
A vertical gap, of one pixel, appears at the right edge, not at the left nor other directions. The pixel colors indicates my background wallpaper. See the attachment.

EXPECTED RESULT
No such a gap.

SOFTWARE VERSIONS
(available in About System)
KDE Plasma Version: 5.12.6
KDE Frameworks Version: 5.48.0
Qt Version: (I don't know how to get the version)
Kernel: x86_64 Linux 4.18.9-100.fc27.x86_64

ADDITIONAL INFORMATION
My screen is 15.6' 1080p. I've tried scaling factors 1.0, 1.3 and 1.5, they all work fine. And it seems a problem only with Qt apps, since my Chrome isn't affected.
Comment 1 lizhujin 2018-10-01 14:37:23 UTC
My Qt version is 5.9.6.
Comment 2 Christoph Feck 2018-10-01 19:56:34 UTC
Please use 'xprop' on the window to check the actual window size after maximizing. I bet Qt does not round the size to full width when scaling is 1.4
Comment 3 Christoph Feck 2018-10-01 20:05:42 UTC
1920/1.4 = 1371.43, which is rounded down to 1371
1371*1.4 = 1919.4, which is again rounded down to 1919.

If you are able to set it to 1.41 in the config files, you should be able to work around this issue:

1920/1.41 = 1361.70, which is rounded up to 1362
1362*1.41 = 1920,42, which is rounded down to 1920.

I doubt this can be fixed in Qt. It would internally have to store window/widget sizes as fractions.
Comment 4 lizhujin 2018-10-02 03:46:44 UTC
(In reply to Christoph Feck from comment #2)
> Please use 'xprop' on the window to check the actual window size after
> maximizing. I bet Qt does not round the size to full width when scaling is
> 1.4

xprop on the troubled window gives the result:

WM_NORMAL_HINTS(WM_SIZE_HINTS):
                user specified size: 1920 by 997
                program specified minimum size: 391 by 307
                program specified resize increment: 1 by 1
                program specified base size: 0 by 0
                window gravity: Static

There seems nothing wrong with the parameters.
Comment 5 lizhujin 2018-10-02 17:41:01 UTC
(In reply to Christoph Feck from comment #3)
> 1920/1.4 = 1371.43, which is rounded down to 1371
> 1371*1.4 = 1919.4, which is again rounded down to 1919.
> 
> If you are able to set it to 1.41 in the config files, you should be able to
> work around this issue:
> 
> 1920/1.41 = 1361.70, which is rounded up to 1362
> 1362*1.41 = 1920,42, which is rounded down to 1920.
> 
> I doubt this can be fixed in Qt. It would internally have to store
> window/widget sizes as fractions.

I manually set the scaling factor to 1.41, and yes, it fixes my problem, though the computation behind the scene is still unclear to me.

I simply put a command into /usr/bin/startkde:
export QT_SCREEN_SCALE_FACTORS="${QT_SCREEN_SCALE_FACTORS//1\.4/1\.41}"

After restarting, the gap disappears.

Thanks for your suggestion!
Comment 6 Martin Flöser 2018-10-04 17:12:21 UTC

*** This bug has been marked as a duplicate of bug 391956 ***