Run stacking while performing movement in osu! composer #28792
Conversation
Previously it would be required to drag to the starting position of the stack which feels weird.
|
It's a bit ugly, but as always it's very localised and should work until it doesn't. I'd say you can continue in the direction (and test performance). |
… times is detected Tangentially found when profiling ppy#28792. For reproduction, import https://osu.ppy.sh/beatmapsets/972#osu/9007, move any object on the playfield, and observe a half-second freeze when ending the drag.
… times is detected Tangentially found when profiling ppy#28792. For reproduction, import https://osu.ppy.sh/beatmapsets/972#osu/9007, move any object on the playfield, and observe a half-second freeze when ending the drag.
|
Performance is passable with #28801, but not great. master: this PR:
I guess one thing that would be suboptimal but fast would be to just fully unstack the object on drag start and re-stack it on drag end? That said, it would be nice to have this post-processing run somehow, because there are other issues like #24006 that cannot be worked around so easily. |
|
Maybe you can expose a way for the osu! ruleset to run post-movement actions, and have it use |
|
Post-movement is too late, re-stacking already happens on post-movement (mouse up). Something has to happen at the start, minimum, if not every frame during. I have hopes that maybe if I just isolate the per-frame part to run stacking exclusively rather than do all of that |
|
That's what I meant, but it was obtuse. Basically some sort of callback here whether a virtual method or otherwise, that the osu implementation can use to invoke that stacking method. |
|
I beelined for the simplest possible variant of that in 37a296b, and it seems to be... acceptable? Not sure about code quality, but yeah.
Mind you, I did try to do a not-full-beatmap pass of the stacking update, but getting the correct indices is not free or even trivial to do. You would think that it would be enough to get the indices of the first and last object in the selection, but that's not enough - you would really need indices of all objects that have alive blueprints that can be snapped to, and fishing that out at the level of |
RFC. Closes #28635.
I was hoping that this was going to be simpler than it is, but it is not. See explanation in inline comments.
I'm not even considering performance implications or testing right now until I see whether the baseline fix survives review.
9cc0e01 is not required (it was a failed attempt to fix the biggest issue with this, which is the jittering mentioned in the inline comments), but felt nice so I included it.