| Summary: | Desktop Grid with Present Windows Effect: Jumping Windows on Effect-End | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | g111 |
| Component: | effects-desktop-grid | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andrej.cremoznik, dan.boff, ericedlund2017, green, kde.org, kde, nate, virgolus |
| Priority: | NOR | Keywords: | reproducible |
| Version: | 4.7.2 | ||
| Target Milestone: | --- | ||
| Platform: | Debian unstable | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=444678 | ||
| Latest Commit: | https://invent.kde.org/plasma/kwin/commit/7a4cabf3287e82e7d1d6ba84b8b059ab470f9f42 | Version Fixed In: | 5.25 |
| Attachments: |
KWin supportInformation
Video of jumpy bahavior |
||
|
Description
g111
2011-12-09 11:46:16 UTC
Correction: Reproducible: Always confirmed. There seems also to be an issue with the removal of paint clipper in 4.8. I cannot promise that we fix it as I plan to rewrite desktop grid for 4.9 This bug seems to be fixed in 4.8 for nvidia hardware and their binary driver. But as Martin points out, there's the screen clipping issue in 4.8 https://bugs.kde.org/show_bug.cgi?id=294322 Hmm, I am using KDE 4.8 from the Fedora personal repos and the Bug is still there. The jumping windows seem to occur if the desktop grid is closed, but the mouse cursor is not hovering over the desktop it is going to zoom into. But only if the highlighting animation is initiated but not completed yet. For example open a two windows (maximize one for better visibility) on the upper left desktop, set the desktop effect animation speed to slow, activate the non-maximized window and then start the dektop grid effect (make sure the desktop with the opened windows is active). Hold the mouse cursor over the desktop the windows are on until the desktop is fully highlighted. Now move the the cursor to the upper right desktop and press esc as soon as the highlight starts switching to that desktop. You will see the windows jumping after the upper left desktop gets maximized. You may also reproduce this by instead of pressing escape waiting until the upper right desktop is fully highlighted and then moving the mouse cursor back to the upper left desktop and pressing lmb. Though I don't know how Kwin works internally it seems as if this bug would be related to the issue discussed here: http://forum.kde.org/viewtopic.php?f=111&t=87901 Because this bug does also show some kind of a leak when two effects (Here higlighting and resizing the windows, there active switch animation and moving windows) are running at the same time. Seems to be fixed in 4.8.80. I cannot reproduce this anymore (KDE 4.11.2). It seems to be fixed?! from bug #294434 Daniel Boff 2014-06-11 09:39:45 UTC ----------------------------------------------------- I have a similar effect on my system, however, for me the problem doesn't seem to be "brightness" related: * Open some windows on your first virtual desktop * I activate the desktop grid effect by a screen corner (bottom right) * -> The effect activates * Click on the first virtual desktop to activate (it again) * -> The windows displayed on the desktop do not move smoothly back into place. After this jumpy behavior occurred, it will not happen again for this desktop until you move windows around on that desktop or open new ones. Switching to a different desktop that the one that was currently active does not lead to a jumpy behavior please provide the output of
qdbus org.kde.kwin /KWin supportInformation
for a wild guess, you could also pre-emptively check whether it also happens with xrender compositing.
Addendum on discussion on bug #294434
bug #327539 is understood and fixed. so whatever you observe is not due to that condition, since your kwin includes the fix
Created attachment 87182 [details]
KWin supportInformation
I did some tests with different compositortypes, every compositor type shows this behavior for me, BUT: * Happens with OpenGL 3.2 and OpenGL 2.0 (I didn't test OpenGL 1.2) * It happens much less likely with XRender * Is much harder to reproduce after changing the compositor type (It is easy to reproduce by changing the compositor and the rebooting, but directly after changing the compositortype the problem is happening much less frequently for me) Created attachment 87190 [details]
Video of jumpy bahavior
Here a video of what this jumpy behavior looks like
Do you have an autohiding panel on the bottom? What if you set it to "always" visible? I have an auto-hiding panel on the left screen edge, but changing it to always visible does not change anything btw changing the present window layout (Natural, Regular grid, Flexible grid) doesnt change this behavior. Maybe it has something todo with how the compositor is initialized? since, the jumpy behavior stops when changing the compositor from ogl to xrender and then back to ogl what about the bottom? it looks like a panel briefly appears, is faded out. the faded in and disappears on exiting desktopgrid. panning? what's the output of "xrandr -q"? This briefly appearing panel is only the top panel for the second virtual desktop (I checked this by setting the animation speed to very slow) xrandr -q Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 DVI-I-0 disconnected primary (normal left inverted right x axis y axis) DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm 1920x1080 60.00*+ 144.00 119.98 99.93 1440x900 119.85 1280x1024 119.96 75.02 60.02 1024x768 119.99 75.03 60.00 800x600 119.97 75.00 60.32 640x480 120.01 75.00 59.94 HDMI-0 disconnected (normal left inverted right x axis y axis) DP-0 disconnected (normal left inverted right x axis y axis) DVI-D-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) Same behaviour after upgrade to KDE Frameworks 5.16.0. Before the upgrade the animation is very smooth and beatiful. I've no auto-hide panel, only a fixed panel on the left of the screen. This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23? I am currently testing this with plasma 5.22.5 (kubuntu 21.04). With plasma 5.22.5 the jumping still happens. But not only when closing the grid, but also when starting the grid effect. This can be seen best if configuring the zoom duration to a bigger value like "2000". When starting the zoom effect, the windows jump to the the uncluttered positions and after this the desktop grid zooming starts. When closing the grid, the windows jump to back to there normal position and after this the grid zoom starts. So in both cases there is no fluent window movement. But at least it is consistent with starting and ending the grid. I will test this with plasma 5.23 (kubuntu 21.10) soon, I hope. I have found a laptop with plasma 5.23.2 (kubuntu 21.10): Here the effect looks different, but still not ok. Set the "zoom duration" to 2000 to see what happens. When activating the effect: * windows jump to the uncluttered position * Some windows overlap out of the desktop border (you can see this with only 3 virtual desktops, so that the bottom right corner is left free in the desktop grid. And with placing a window into the right bottom corner of the first virtual desktop) * then zooming starts When closing the effect everything moves exactly backwards (here the order of what happens did change compared to plasma 5.22.5) * The desktop grid zooms back and the windows zoom smoothly bigger, but they are still placed in the uncluttered position, so that they overlap out of the desktop border. * After the desktop zooming has finished the windows jump back to their normal position. So it is still not perfect. *** This bug has been marked as a duplicate of bug 444678 *** *** Bug 447472 has been marked as a duplicate of this bug. *** Git commit 7a4cabf3287e82e7d1d6ba84b8b059ab470f9f42 by Marco Martin. Committed on 06/05/2022 at 10:44. Pushed by mart into branch 'master'. QML version of the Desktop Grid effect Replace completely the old desktop grid effect with a QML version. Aims to feature parity and be a change as transparent as possible for the user. Related: bug 433071, bug 452625, bug 443971, bug 437121, bug 452925, bug 437928, bug 452439, bug 450254, bug 450106, bug 447832, bug 449960, bug 416576, bug 441862, bug 444859, bug 445999, bug 422117, bug 404627, bug 435483, bug 420744, bug 435482, bug 427055, bug 333445, bug 429120, bug 427391, bug 409295, bug 294322, bug 356955 FIXED-IN: 5.25 M +5 -0 src/effects.cpp M +10 -5 src/effects/desktopgrid/CMakeLists.txt D +0 -1571 src/effects/desktopgrid/desktopgrid.cpp D +0 -186 src/effects/desktopgrid/desktopgrid.h D +0 -32 src/effects/desktopgrid/desktopgrid.kcfg M +6 -14 src/effects/desktopgrid/desktopgrid_config.cpp M +2 -2 src/effects/desktopgrid/desktopgrid_config.h M +68 -144 src/effects/desktopgrid/desktopgrid_config.ui A +32 -0 src/effects/desktopgrid/desktopgridconfig.kcfg M +5 -1 src/effects/desktopgrid/desktopgridconfig.kcfgc A +342 -0 src/effects/desktopgrid/desktopgrideffect.cpp [License: GPL(v2.0+)] A +108 -0 src/effects/desktopgrid/desktopgrideffect.h [License: GPL(v2.0+)] M +5 -4 src/effects/desktopgrid/main.cpp D +0 -26 src/effects/desktopgrid/main.qml M +1 -0 src/effects/desktopgrid/metadata.json A +255 -0 src/effects/desktopgrid/qml/DesktopView.qml [License: GPL(v2.0+)] A +193 -0 src/effects/desktopgrid/qml/main.qml [License: GPL(v2.0+)] M +22 -5 src/effects/private/qml/WindowHeap.qml M +21 -3 src/libkwineffects/kwineffects.h M +4 -1 src/libkwineffects/kwinquickeffect.cpp https://invent.kde.org/plasma/kwin/commit/7a4cabf3287e82e7d1d6ba84b8b059ab470f9f42 |