When maximizing a Wayland client it is not animated. X clients animate just fine. When doing so I noticed that the order and amount of signals emitted is different for the two: Maximizing an X client: Shape changed old was QRect(0,0 682x512) Shape changed old was QRect(0,0 1024x768) Shape changed old was QRect(0,0 682x512) Maximized changed true true Maximizing a Wayland client: Shape changed old was QRect(342,260 682x512) Maximized changed true true Shape changed old was QRect(342,260 682x512)
Output with new geometries: X client Shape changed old was QRect(432,232 682x512) now is QRect(432,232 682x508) Shape changed old was QRect(0,0 1024x768) now is QRect(0,0 1024x768) Shape changed old was QRect(432,232 682x512) now is QRect(0,0 1024x768) Maximized changed true true Wayland client: Shape changed old was QRect(251,350 1024x768) now is QRect(251,350 1024x768) Maximized changed true true Shape changed old was QRect(251,350 1024x768) now is QRect(0,0 1024x768) (this is the output from when double clicking the title bar to maximize, I do get geometry changed events when moving the window, obviously, but in the instance of maximizing there's some superfluous events)
This used to work in the past, given that I assume it's another Qt 5.9 regression. I'm not going to investigate prior to xdg shell v6 support landed.
We might have to fork the effect and have it work differently for X11 and Wayland windows.
*** Bug 390185 has been marked as a duplicate of this bug. ***
(In reply to Martin Flöser from comment #3) > We might have to fork the effect and have it work differently for X11 and > Wayland windows. IMO, that's wrong. Maximize effect do scaling and translation in a virtual space, that's all! It doesn't need to know whether it's Wayland or X11 or whatever. The root of the problem is manual tracking of window geometries. KWin knows what previous geometry was so it should provide it to the effect. I'd taken this approach in https://phabricator.kde.org/D9391 Beside, the maximize effect tracks all geometry changes, that's totally wrong, right? Another problem is that in some cases KWin changes geometry multiple times behind scenes. This leads to "visual artifacts". Yet another problem is cross fading. "Note: the window pixmap is not kept forever even when referenced". This is a broken contract between effects and core KWin. https://github.com/KDE/kwin/blob/master/libkwineffects/kwineffects.h#L2211 Also, it doesn't work on Wayland. In the best scenario, each window should have a state log so effects could look up previous state and do whatever they want. E.g. auto currentGeo = w->stateLog()->current().geometry(); auto prevGeo = w->stateLog()->previous().geometry(); morphGeometry(w, prevGeo, currentGeo); But this would be really big change also it's not really clear how to handle state log(e.g. how to merge states, etc). Yet, I wish KWin had this. I suggest to change windowMaximizedStateChanged's prototype to void windowMaximizedStateChanged(EffectWindow *w, const MaximizeChangedData &data); struct MaximizeChangedData { bool vertically; bool horizontally; QRect oldGeometry; QRect newGeometry; }; so effects have at least minimum required information. Also, it would break compatibility with third-party effects. But if I were asked to choose between working effects and compatibility I would choose "workking effects".
(In reply to Vlad Zagorodniy from comment #5) > (In reply to Martin Flöser from comment #3) > > We might have to fork the effect and have it work differently for X11 and > > Wayland windows. > > IMO, that's wrong. Maximize effect do scaling and translation in a virtual > space, that's all! It doesn't need to know whether it's Wayland or X11 or > whatever. The reason I wrote that is a conceptional difference between X11 and Wayland when maximizing windows. On X11: * window manager resizes window * window manager sets the maximized state On Wayland: * window manager sets state to maximized * window manager sends a configure request to the window with the new state and the new geometry * window renders to new size and only at that time the geometry changes Ideally we would only apply the state change when the new size is acknowledged. But that's something KWin cannot do and something I doubt is worth the effort. And that's what's breaking the maximize effect. When it reacts on the maximized changed signal, the window doesn't have the right geometry yet. > > The root of the problem is manual tracking of window geometries. KWin knows > what previous geometry was so it should provide it to the effect. I'd taken > this approach in https://phabricator.kde.org/D9391 > > Beside, the maximize effect tracks all geometry changes, that's totally > wrong, right? Well it has to for the problem like on Wayland that maximize and geometry change are not synced. > > Another problem is that in some cases KWin changes geometry multiple times > behind scenes. This leads to "visual artifacts". That shouldn't happen. The behind the scene changes should have geometry update blockers, so that in the end there is only a change from old to new geometry. > > Yet another problem is cross fading. "Note: the window pixmap is not kept > forever even when referenced". This is a broken contract between effects and > core KWin. The contract is that there is no guarantee. So the contract cannot be broken. > https://github.com/KDE/kwin/blob/master/libkwineffects/kwineffects.h#L2211 > Also, it doesn't work on Wayland. It should work on Wayland as well ;-) I have seen it working in the past. > > > In the best scenario, each window should have a state log so effects could > look up previous state and do whatever they want. E.g. > > auto currentGeo = w->stateLog()->current().geometry(); > auto prevGeo = w->stateLog()->previous().geometry(); > morphGeometry(w, prevGeo, currentGeo); > > But this would be really big change also it's not really clear how to handle > state log(e.g. how to merge states, etc). Yet, I wish KWin had this. I think that is not possible. > > > I suggest to change windowMaximizedStateChanged's prototype to > > void windowMaximizedStateChanged(EffectWindow *w, const MaximizeChangedData > &data); > > struct MaximizeChangedData { > bool vertically; > bool horizontally; > QRect oldGeometry; > QRect newGeometry; > }; > > so effects have at least minimum required information. Also, it would break > compatibility with third-party effects. But if I were asked to choose > between working effects and compatibility I would choose "workking effects". The old signal could be kept for compatibility. I'm not sure that sending this information would really help the situation for the Wayland case.
(In reply to Martin Flöser from comment #6) > The reason I wrote that is a conceptional difference between X11 and Wayland > when maximizing windows. > > On X11: > * window manager resizes window > * window manager sets the maximized state > > On Wayland: > * window manager sets state to maximized > * window manager sends a configure request to the window with the new state > and the new geometry > * window renders to new size and only at that time the geometry changes > > Ideally we would only apply the state change when the new size is > acknowledged. But that's something KWin cannot do and something I doubt is > worth the effort. > > And that's what's breaking the maximize effect. When it reacts on the > maximized changed signal, the window doesn't have the right geometry yet. > Well it has to for the problem like on Wayland that maximize and geometry > change are not synced. > The old signal could be kept for compatibility. > > I'm not sure that sending this information would really help the situation > for the Wayland case. Oh, I was thinking that KWin hides the xdg shell protocol specifics. Silly me. As you see the maximize effect is exposed too much to low-level details. What about if a next version of the xdg shell protocol totally breaks compatibility with the previous ones? [It most likely won't happen but let's imagine it could.] That would break effects! Anyways, it would be great to send that information to effects because in most cases effects are "abstract" (they do affine transformations, etc) and don't care what platform it is, etc. Beside that, supplying effects with all they need makes them less error prone.
Here wayland clients are animated if I drag the window up/down to maximize/unmaximize it. There is no animation when I click the buttons in the window decoration or double click the window decoration. plasma 5.13, frameworks 5.47 and qt 5.11 on Arch Linux.
Fixed by * https://phabricator.kde.org/R108:e327cce4bc92aa028c7aefcec13f6239b08aa5bf * https://phabricator.kde.org/R108:65b8ba1770c21ed96e5faa4615623a4cddd79928