Bug 288530 - Desktop Grid with Present Windows Effect: Jumping Windows on Effect-End
Summary: Desktop Grid with Present Windows Effect: Jumping Windows on Effect-End
Alias: None
Product: kwin
Classification: Plasma
Component: effects-desktop-grid (show other bugs)
Version: 4.7.2
Platform: Debian unstable Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
: 447472 (view as bug list)
Depends on:
Reported: 2011-12-09 11:46 UTC by g111
Modified: 2022-05-06 10:46 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.25

KWin supportInformation (4.56 KB, text/plain)
2014-06-14 11:42 UTC, Daniel Boff
Video of jumpy bahavior (1.17 MB, video/x-matroska)
2014-06-14 12:42 UTC, Daniel Boff

Note You need to log in before you can comment on or make changes to this bug.
Description g111 2011-12-09 11:46:16 UTC
Version:           4.7.2 (using KDE 4.7.2) 
OS:                Linux

I have configured the desktop grid (ctrl+F8) so that it is using the present windows effect. Activating the desktop grid scales and moves the windows smoothly into the correct position of the present windows layout while the desktop grid is zooming out.

Closing the desktop grid zooms the current desktop back to its original size. What does not look so nice: While zooming happens, the windows are kept in there present windows position. So the desktop is zoomed, but the windows are not smoothly scaled and positioned back to there original position. Instead they are resized in one step (jumpy, without an animation) after the desktop grid has finished zooming.

Reproducible: Didn't try

Steps to Reproduce:
Configure the desktop grid to use the present windows effect. Activate the desktop grid (e.g. by pressing ctrl+F8). Close the desktop grid again (e.g. by pressing Escape). Watch the window zooming.

Actual Results:  
When closing the grid, the windows are not smoothly moved back to there original position. Instead they jump back after grid has been closed.

Expected Results:  
The windows should smoothly move back to there original position, right backward as they have been smoothly moved into the present windows position before.

Tell me if you need more info.
Comment 1 g111 2011-12-09 11:47:23 UTC
Reproducible: Always
Comment 2 Martin Flöser 2011-12-09 11:56:24 UTC
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
Comment 3 Andrej Čremožnik 2012-02-18 11:39:34 UTC
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
Comment 4 Björn Sonnenschein 2012-02-19 14:29:24 UTC
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.
Comment 5 Janek Bevendorff 2012-06-07 21:04:48 UTC
Seems to be fixed in 4.8.80.
Comment 6 g111 2013-11-07 13:47:47 UTC
I cannot reproduce this anymore (KDE 4.11.2). It seems to be fixed?!
Comment 7 Thomas Lübking 2014-06-12 20:42:37 UTC
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
Comment 8 Thomas Lübking 2014-06-12 20:44:00 UTC
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
Comment 9 Daniel Boff 2014-06-14 11:42:20 UTC
Created attachment 87182 [details]
KWin supportInformation
Comment 10 Daniel Boff 2014-06-14 12:27:05 UTC
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)
Comment 11 Daniel Boff 2014-06-14 12:42:14 UTC
Created attachment 87190 [details]
Video of jumpy bahavior

Here a video of what this jumpy behavior looks like
Comment 12 Thomas Lübking 2014-06-14 13:45:35 UTC
Do you have an autohiding panel on the bottom?
What if you set it to "always" visible?
Comment 13 Daniel Boff 2014-06-14 17:21:53 UTC
I have an auto-hiding panel on the left screen edge, but changing it to always visible does not change anything
Comment 14 Daniel Boff 2014-06-14 17:25:21 UTC
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
Comment 15 Thomas Lübking 2014-06-14 17:28:10 UTC
what about the bottom?
it looks like a panel briefly appears, is faded out. the faded in and disappears on exiting desktopgrid.

what's the output of "xrandr -q"?
Comment 16 Daniel Boff 2014-06-15 10:58:35 UTC
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)
Comment 17 Ezio Vergine 2015-12-14 22:18:38 UTC
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.
Comment 18 kde.org 2021-11-06 17:53:49 UTC
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
Comment 19 g111 2021-11-08 08:19:39 UTC
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.
Comment 20 g111 2021-11-08 08:48:57 UTC
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.
Comment 21 Nate Graham 2021-11-08 17:19:35 UTC

*** This bug has been marked as a duplicate of bug 444678 ***
Comment 22 Nate Graham 2022-03-08 13:53:27 UTC
*** Bug 447472 has been marked as a duplicate of this bug. ***
Comment 23 Marco Martin 2022-05-06 10:46:21 UTC
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