Bug 480684 - Window restore via mouse-drag appears non-atomic due to delayed resize
Summary: Window restore via mouse-drag appears non-atomic due to delayed resize
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: 5.27.10
Platform: openSUSE Linux
: NOR minor
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-01 14:52 UTC by neobrain
Modified: 2024-03-14 07:09 UTC (History)
1 user (show)

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


Attachments
Slow-motion screen recording (1.37 MB, video/webm)
2024-02-01 14:52 UTC, neobrain
Details
Window restore, frame 1 (526.39 KB, image/png)
2024-02-01 14:56 UTC, neobrain
Details
Window restore, frame 2 (742.14 KB, image/png)
2024-02-01 14:57 UTC, neobrain
Details
Window restore, frame 3 (907.88 KB, image/png)
2024-02-01 14:57 UTC, neobrain
Details
Window restore, frame 4 (1.16 MB, image/png)
2024-02-01 14:57 UTC, neobrain
Details

Note You need to log in before you can comment on or make changes to this bug.
Description neobrain 2024-02-01 14:52:11 UTC
Created attachment 165440 [details]
Slow-motion screen recording

SUMMARY
When de-maximizing windows by dragging them with the mouse, the window-restore effect is spread across multiple presentation frames: First, the window "unsnaps" from the top of the screen, and it only shortly after that it resizes to its original size.

In effect, it looks as if the window jumped around before restoring its actual size. This is particularly noticeable with the wobbly windows effect, where the window corners will be unevenly stretched at its corners.

I attached a slow-motion video to illustrate: Stepping through it frame by frame you can see that 1. The window unsnaps (note the top-left corner being on a different height than the top-right one), 2. The wobbliness calms down but the window is still in maximum size, 3. The window resize kicks in, triggering another wobble.

This might be a Wayland-specific issue.

STEPS TO REPRODUCE
(0. Test on Wayland)
1. Maximize a window
2. Drag the window from its title bar to restore its size
3. Closely observe the result, as this glitch happens within 2-3 presentation frames

OBSERVED RESULT
The restore operation is non-atomic: The window unsnaps before being resized

EXPECTED RESULT
The window should start resizing in the same frame that its top-left corner moves.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.27.10
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.114.0
Qt Version: 5.15.12

ADDITIONAL INFORMATION
I'm also observing this glitch in a Parallels VM, where it can be prolonged by continuously moving the mouse cursor. This will delay the window resize until the cursor stops moving. Maybe this gives a hint on the nature of the issue?
Comment 1 neobrain 2024-02-01 14:56:33 UTC
Created attachment 165441 [details]
Window restore, frame 1
Comment 2 neobrain 2024-02-01 14:57:05 UTC
Created attachment 165442 [details]
Window restore, frame 2
Comment 3 neobrain 2024-02-01 14:57:24 UTC
Created attachment 165443 [details]
Window restore, frame 3
Comment 4 neobrain 2024-02-01 14:57:36 UTC
Created attachment 165444 [details]
Window restore, frame 4
Comment 5 neobrain 2024-02-01 15:01:44 UTC
Attached the relevant frames as pictures for convenience.
Frames 1 and 2 are right after the unsnapping and during calming down of the wobbliness.
Frame 3 is when the actual resize seems to kick in (and when another wobble begins).
Frame 4 is shortly before everything calms down.
Comment 6 Nate Graham 2024-02-06 22:52:56 UTC
The effect has been tweaked a bit in Plasma 6 and I'm unable to reproduce the issue there. So for now I'll mark this as fixed, but do feel free to re-open it if you find that the issue is still present after you upgrade to Plasma 6. Thanks a lot!
Comment 7 neobrain 2024-03-14 07:09:40 UTC
Having updated to Plasma 6 today, I can confirm the issue is fixed :)