https://bugs.kde.org/show_bug.cgi?id=384462
--- Comment #6 from Martin Flöser <mgraess...@kde.org> --- (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. -- You are receiving this mail because: You are watching all bug changes.
