Bug 481460 - With fractional scale factors on Wayland, Zoom window enlarges continuously without user interaction
Summary: With fractional scale factors on Wayland, Zoom window enlarges continuously w...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 5.93.0
Platform: Other Linux
: HI normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: qt6, wayland
: 483605 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-02-17 12:01 UTC by Iyán Méndez Veiga
Modified: 2024-03-23 15:45 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.0.3
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Iyán Méndez Veiga 2024-02-17 12:01:55 UTC
SUMMARY
This is a funny issue. I don't know if it's caused by Qt 6.7 or by some changes in Plasma 6. I also remember having a similar issue with Inkscape in the past before it started to work correctly as a native Wayland app, so probably this only affects XWayland apps.

When opening certain windows (e.g., the "Share screen" window during a call), they enlarge continuously and indefinitely without user interaction. It's hard to describe so I will try to record a video later. The window first starts to expand to the right of the desktop. Once it reaches the end of the screen, it starts to push the window to the left so it gives the impression the app is expanding to the left. When all the width is used, the window continues to expand to the right outside the screen range.

STEPS TO REPRODUCE
1. Open Zoom (probably other XWayland apps suffer from this issue too)
2. Start a call
3. Open Share screen window

OBSERVED RESULT
What is described above, the window continuously expands its width to the right. 

EXPECTED RESULT
Window has a fixed size unless the user manually changes it

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 5.93.0
KDE Frameworks Version: 5.249.0
Qt Version: 6.7.0
Kernel Version: 6.7.4-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 8 × 11th Gen Intel® Core™ i5-1135G7 @ 2.40GHz
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics
Manufacturer: LENOVO
Product Name: 20XYCTO1WW
System Version: ThinkPad X1 Yoga Gen 6
Comment 1 Iyán Méndez Veiga 2024-02-17 12:19:51 UTC
Here is a video of the issue:
https://drive.switch.ch/index.php/s/HKnY7QNkw8BP69m
Comment 2 Vlad Zahorodnii 2024-02-19 14:12:23 UTC
What scale factor do you use? Is it reproducible with x1?
Comment 3 Iyán Méndez Veiga 2024-02-19 16:04:44 UTC
(In reply to Vlad Zahorodnii from comment #2)
> What scale factor do you use? Is it reproducible with x1?

125%, and I cannot reproduce on X11 with global scale set to 100% or 125%.
Comment 4 Vlad Zahorodnii 2024-02-19 16:08:52 UTC
By "x1", I meant a scale factor of 1
Comment 5 Iyán Méndez Veiga 2024-02-19 16:25:25 UTC
(In reply to Vlad Zahorodnii from comment #4)
> By "x1", I meant a scale factor of 1
Sorry, my bad. No, also in Wayland with 100% I cannot reproduce the issue. It only happens with certain fractional scale levels. For example, 125% triggers changing the width, while 150% triggers changing the height, although that finish early because I guess the window has some hardcoded maximum height.

Here is a new video testing different scale levels:
https://drive.switch.ch/index.php/s/R04sQcItuKyc83S

The video also shows two other (minor) issues:
1. Two mouses are recorded in Wayland
2. The blue line in the display configuration for some scales is a thin bottom line, but others is a grading using all the rectangle space.
Comment 6 Iyán Méndez Veiga 2024-02-19 16:35:45 UTC
> 2. The blue line in the display configuration for some scales is a thin
> bottom line, but others is a grading using all the rectangle space.
This I have reported in more detail in Bug 481550
Comment 7 David Edmundson 2024-02-22 13:39:54 UTC
I was unable to sort out having a zoom account, could you test something for me

 - create a window rule for zoom
-  force the title or something so you know the rule is matching
 - set "obey geometry restrictions" and force it to no

See if the bug still manifests
Comment 8 Iyán Méndez Veiga 2024-02-23 13:44:01 UTC
(In reply to David Edmundson from comment #7)
> I was unable to sort out having a zoom account, could you test something for
> me
> 
>  - create a window rule for zoom
> -  force the title or something so you know the rule is matching
>  - set "obey geometry restrictions" and force it to no
> 
> See if the bug still manifests

The bug still manifests. I was not sure if the rule was matching so I tested with settings fullscreen force set to yes. In that case, all Zoom windows are indeed fullscreen, including the share screen one (without the bug in this case). But with "obey geometry restrictions" set to no, I still have the same issue.
Comment 9 fanzhuyifan 2024-03-20 01:59:18 UTC
FWIW I can reproduce with 125% scale, 2560x1600 screen. Qt 6.7, arch linux, wayland, zoom 5.17.10-1.

The 125% scale seems quite important, since I can't reproduce if I use 115%, 120%, 130%, or 135% scale.
Comment 10 fanzhuyifan 2024-03-20 02:01:56 UTC
*** Bug 483605 has been marked as a duplicate of this bug. ***
Comment 11 fanzhuyifan 2024-03-20 02:02:20 UTC
(In reply to fanzhuyifan from comment #10)
> *** Bug 483605 has been marked as a duplicate of this bug. ***

I can also reproduce  with 250%, as reported in 483605.
Comment 12 fanzhuyifan 2024-03-20 02:03:43 UTC
As mentioned in Bug 483605, a necessary condition is checking Legacy Applications Apply Scaling themselves.
Comment 13 fanzhuyifan 2024-03-20 05:43:06 UTC
Currently toXNative [0] rounds halfs away from 0, and we get increasing window sizes. If we change it to round halfs towards 0, we get decreasing window sizes. If we change it to round halfs to even, the problem seems to disappear.

It seems the scale 1.25 is special because it can exactly generate integer + 0.5 when multiplied by an integer. I have no idea what the root cause of the problem is though. (This hypothesis is consistent with the problem also being reported for scale=1.5 and and scale=2.5).

[0] https://invent.kde.org/plasma/kwin/-/blob/master/src/utils/xcbutils.cpp?ref_type=heads#L624
Comment 14 fanzhuyifan 2024-03-20 06:25:58 UTC
(In reply to fanzhuyifan from comment #13)
> Currently toXNative [0] rounds halfs away from 0, and we get increasing
> window sizes. If we change it to round halfs towards 0, we get decreasing
> window sizes. If we change it to round halfs to even, the problem seems to
> disappear.
> 
> It seems the scale 1.25 is special because it can exactly generate integer +
> 0.5 when multiplied by an integer. I have no idea what the root cause of the
> problem is though. (This hypothesis is consistent with the problem also
> being reported for scale=1.5 and and scale=2.5).
> 
> [0]
> https://invent.kde.org/plasma/kwin/-/blob/master/src/utils/xcbutils.
> cpp?ref_type=heads#L624

The actual problem seems to be that the code is rounding both frame size and client size to have integral XNative sizes.
However, their difference, the border size, does not always have integral XNative sizes [1]. Hence, we get cycles of rounding, and in this particular case, this leads to infinitely growing window sizes when we round up.

[1] https://invent.kde.org/plasma/kwin/-/blob/master/src/x11window.cpp?ref_type=heads#L2834
Comment 15 Bug Janitor Service 2024-03-20 15:00:13 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5489
Comment 16 fanzhuyifan 2024-03-20 21:32:07 UTC
Git commit 111657ad04e7627d6e3c7b345a48670459cdeacc by Yifan Zhu.
Committed on 20/03/2024 at 21:24.
Pushed by fanzhuyifan into branch 'master'.

x11window: round border size to integral XNative units

Both frameSize and clientSize are rounded to integral XNative units.
So their difference must also be rounded to integral XNative units.
Otherwise we get cycles of rounding that can cause growing window sizes.

M  +5    -0    src/utils/xcbutils.cpp
M  +7    -0    src/utils/xcbutils.h
M  +14   -8    src/x11window.cpp

https://invent.kde.org/plasma/kwin/-/commit/111657ad04e7627d6e3c7b345a48670459cdeacc
Comment 17 fanzhuyifan 2024-03-20 21:48:28 UTC
Git commit 5af86d18f406da03d194c464ac63bbb600aebc89 by Yifan Zhu.
Committed on 20/03/2024 at 21:37.
Pushed by fanzhuyifan into branch 'Plasma/6.0'.

x11window: round border size to integral XNative units

Both frameSize and clientSize are rounded to integral XNative units.
So their difference must also be rounded to integral XNative units.
Otherwise we get cycles of rounding that can cause growing window sizes.


(cherry picked from commit 111657ad04e7627d6e3c7b345a48670459cdeacc)

M  +5    -0    src/utils/xcbutils.cpp
M  +7    -0    src/utils/xcbutils.h
M  +14   -8    src/x11window.cpp

https://invent.kde.org/plasma/kwin/-/commit/5af86d18f406da03d194c464ac63bbb600aebc89
Comment 18 Ilya Bizyaev 2024-03-23 15:45:56 UTC
This fixes Godot for me with Qt 6.6.2