Summary: | When windows appear on a vertical screen, they first appear rotated 180 degrees before they are rendered correctly | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Oded Arbel <oded> |
Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | nate, xaver.hugl |
Priority: | NOR | Keywords: | qt6 |
Version: | git master | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/kwin/-/commit/515f60cb7f94b01311a81360a5884409eb2199f3 | 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.
Snapshot from the video showing the first incorrect render Screenshot of the display configuration |
Created attachment 166005 [details]
Snapshot from the video showing the first incorrect render
Created attachment 166006 [details]
Screenshot of the display configuration
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. Is this issue reproducible with only one monitor? and default placement policy (Centered)? (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". Can reproduce, if I set "Glide" as the window open/close animation A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5286 (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. (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...). 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 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 (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 although I'm not sure how actionable it will be given that we are unable to reproduce the glitch (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. |
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.