Bug 481664 - When windows appear on a vertical screen, they first appear rotated 180 degrees before they are rendered correctly
Summary: When windows appear on a vertical screen, they first appear rotated 180 degre...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: git master
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: qt6
Depends on:
Blocks:
 
Reported: 2024-02-22 10:34 UTC by Oded Arbel
Modified: 2024-02-24 01:31 UTC (History)
2 users (show)

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


Attachments
Screencast showing the flickering. If you pause on the correct frame, you can see the rotated rendering. (3.35 MB, video/mp4)
2024-02-22 10:34 UTC, Oded Arbel
Details
Snapshot from the video showing the first incorrect render (408.16 KB, image/jpeg)
2024-02-22 10:35 UTC, Oded Arbel
Details
Screenshot of the display configuration (62.54 KB, image/png)
2024-02-22 10:35 UTC, Oded Arbel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oded Arbel 2024-02-22 10:34:46 UTC
Created attachment 166004 [details]
Screencast showing the flickering. If you pause on the correct frame, you can see the rotated rendering.

SUMMARY
Running Neon testing with wayland with one vertical screen and one horizontal screen, when a window is supposed to appear on the vertical screen it first appears at the bottom right corner rotated 180 degrees (so possibly its the top left corner from the window's perspective) - for a fraction of a second, before it is rendered correctly. When the window is removed, it first rendered rotated again - for a fraction of a second, before being removed


STEPS TO REPRODUCE
1.  Configure an external monitor to be in vertical orientation
2. Move the mouse cursor to the vertical screen
3. Launch an application

OBSERVED RESULT
There's a flicked as the new window first appears rotated and then renders normally.

EXPECTED RESULT
The new window should not flicker.

SOFTWARE/OS VERSIONS
Operating System: KDE neon Testing Edition
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.5.0-17-generic (64-bit)
Graphics Platform: Wayland
Processors: 20 × 12th Gen Intel® Core™ i7-12700H
Memory: 31.0 GiB of RAM
Graphics Processor: Mesa Intel® Graphics

kwin_wayland --version -> 6.0.0
apt policy kwin-wayland -> 4:5.91.90+p22.04+vstable+git20240220.0137-0

ADDITIONAL INFORMATION
See attached screencast for how it looks.
Comment 1 Oded Arbel 2024-02-22 10:35:28 UTC
Created attachment 166005 [details]
Snapshot from the video showing the first incorrect render
Comment 2 Oded Arbel 2024-02-22 10:35:50 UTC
Created attachment 166006 [details]
Screenshot of the display configuration
Comment 3 Oded Arbel 2024-02-22 10:38:55 UTC
The Dr Konqi window in the screencast was there basically to make the window placement algorithm's work more interesting (I'm using the default "Minimal Overlapping" algo) and it otherwise completely unrelated to this issue.
Comment 4 Vlad Zahorodnii 2024-02-22 12:07:24 UTC
Is this issue reproducible with only one monitor? and default placement policy (Centered)?
Comment 5 Oded Arbel 2024-02-22 12:17:22 UTC
(In reply to Vlad Zahorodnii from comment #4)
> Is this issue reproducible with only one monitor? and default placement
> policy (Centered)?

The screencast is a reproduction of the problem on my one external vertical monitor, where the problem does not appear when the new windows are to be shown on the laptop's built-in monitor - when configured in the default horizontal mode.

I tried setting the laptop's built-in screen to vertical mode, and the problem reproduces on the built-in screen in either vertical orientation (left or right) but not in either horizontal orientation (normal or upside-down). Next week I will be able to test this issue in my office where I have 2 external vertical screens.

On my system the window placement was set to "Minimal Overlapping", which is what the screencast shows, but I tested it with "Centered" and it behaves the same except that the new window first appears rotated in the middle of the screen - so the flickering is less annoying (still annoying, but much less).

*) I was sure that "Minimal Overlapping" was the default because it didn't have the orange highlight of non-default configuration - but apparently that feature isn't available for most of the "Window Behavior" configurations , except for "Window activation policy".
Comment 6 Zamundaaa 2024-02-22 15:55:18 UTC
Can reproduce, if I set "Glide" as the window  open/close animation
Comment 7 Bug Janitor Service 2024-02-23 10:16:13 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5286
Comment 8 Oded Arbel 2024-02-23 12:27:16 UTC
(In reply to Zamundaaa from comment #6)
> Can reproduce, if I set "Glide" as the window  open/close animation

I don't believe the "Glide" animation is responsible - my reproduction is with the default "Scale" animation.
Comment 9 Oded Arbel 2024-02-23 12:31:57 UTC
(In reply to Vlad Zahorodnii from comment #4)
> Is this issue reproducible with only one monitor? and default placement
> policy (Centered)?

BTW - this definitely reproduces for me on a single display (just the laptop built in, though operating the touch pad in that configuration is an "interesting" exercise...).
Comment 10 Vlad Zahorodnii 2024-02-23 14:04:27 UTC
Git commit 7c0a88f34b568fdcb205c53a27b440e77cd9a73c by Vlad Zahorodnii.
Committed on 23/02/2024 at 13:57.
Pushed by vladz into branch 'master'.

plugins/glide: Fix rotation order when applying render target transformation

The perspective projection matrix has its y axis flipped vertically. It
should be undone when applying the render target transformation, otherwise
the rotation order will be wrong.

M  +5    -1    src/plugins/glide/glide.cpp

https://invent.kde.org/plasma/kwin/-/commit/7c0a88f34b568fdcb205c53a27b440e77cd9a73c
Comment 11 Vlad Zahorodnii 2024-02-23 15:00:04 UTC
Git commit 515f60cb7f94b01311a81360a5884409eb2199f3 by Vlad Zahorodnii.
Committed on 23/02/2024 at 14:51.
Pushed by vladz into branch 'Plasma/6.0'.

plugins/glide: Fix rotation order when applying render target transformation

The perspective projection matrix has its y axis flipped vertically. It
should be undone when applying the render target transformation, otherwise
the rotation order will be wrong.


(cherry picked from commit 7c0a88f34b568fdcb205c53a27b440e77cd9a73c)

M  +5    -1    src/plugins/glide/glide.cpp

https://invent.kde.org/plasma/kwin/-/commit/515f60cb7f94b01311a81360a5884409eb2199f3
Comment 12 Vlad Zahorodnii 2024-02-23 15:09:07 UTC
(In reply to Oded Arbel from comment #8)
> (In reply to Zamundaaa from comment #6)
> > Can reproduce, if I set "Glide" as the window  open/close animation
> 
> I don't believe the "Glide" animation is responsible - my reproduction is
> with the default "Scale" animation.

Similar to Xaver, I'm able to reproduce the issue only when using Glide. Reopen the bug report if the issue is still present in the final release
Comment 13 Vlad Zahorodnii 2024-02-23 15:09:46 UTC
although I'm not sure how actionable it will be given that we are unable to reproduce the glitch
Comment 14 Oded Arbel 2024-02-23 16:24:00 UTC
(In reply to Vlad Zahorodnii from comment #12)
> Similar to Xaver, I'm able to reproduce the issue only when using Glide.
> Reopen the bug report if the issue is still present in the final release

Ok, I'm not sure what was going on but I tried to reproduce the issue with the glide animation. I also changed its settings - the default animation is a 3 degree turn which is almost unnoticeable, so I increased it - and slowed the animation and I can indeed clearly see that the Glide animation being rotated is indeed the same problem (though - it looks rotated 180 degrees, not just vertically flipped, so the X axis would also be flipped?).

Then I've reset the animation back to the default - and now I cannot reproduce the issue... it seems like my system was actually set to use "Glide" but due to the default glide settings being very subtle, and the animation speed (that was set here to be faster than default) I didn't notice that it wasn't "Scale" and the effects KCM showed the default configuration even though it wasn't. ¯\_(ツ)_/¯

I'll probably change to glide again anyway, because I like that animation.