Open SpomJ opened 2 weeks ago
I don't think this is a good idea overall... No OS / DE does this.
I mean OS/DEs generally don't really do animations the way Hyprland does so there's that...
I suppose it would be nice to see first and decide whether it's worth it second, but that's not how programming works. IMO it would be better for slower and/or more linear-like animations since currently the snap is already noticeable at 3s animation duration (if the curve is sane ofc) when toggling large tile into a small float.
May as well not be worth the hassle, but again, would be interesting to see.
we used to have a similar thing to what KDE does and it was heavily requested to be removed, thus it was.
we used to have a similar thing to what KDE does
What was the thing?
take a snapshot at the beginning of animation and render it on top of the new surface contents, fading out the old
I can see why people didn't want that one, it freezed a certain frame, which produces janky visuals when the contents are moving on their own, which wouldn't happen here.
I think it'd be nice to hear someone else's opinion on this
feel free to gather opinions
Description
The way window animations work currently is the following:
What I propose is to make a flag to make [certain] animations behave like the following: retrieve the target window size from the animation each frame and for each frame send a resizing event to the window, making it actually follow the animation. Because some software doesn't adapt to this well it wouldn't hurt to allow sending events every N frames, interpolating the rest the old way, and/or a windowrule to toggle this for specific groups of windows.
The target behavior is something akin to what happens when you manually resize the window (by dragging)
What this hopes to accomplish is to get rid of the "flickering" caused by scaling suddenly changing when window drastically changes size.