-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix lag when dragging first slider control point in editor #26499
Conversation
test failures require attention |
It would have very weird implications when combined with the position bindable which would be all wrong and stuff
|
||
// It's important that this is done in UpdateAfterChildren so that the SliderBody has a chance to update its Size and PathOffset on Update. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These kinds of changes always scare me, because I'm never sure if this is going to be changing the delay between input handling / positioning. ie. this is responsible for changing the slider ball's position, which also controls the hit area of the follow circle.
I think this is okay though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if it's just me but I feel like there's a half of an explanation missing here. I don't understand what this change has to do with the rest of the diff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that too. The inline comment doesn't do much to explain the actual hidden reason, so needs improvement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added clarification that this is because PlaySliderBody
schedules a refresh once on Update whenever the slider path gets edited.
This doesn't really help my performance much. In cases where there are a sane number of control points I can't notice the difference, but when I made a slider with an insane number of control points it was bad in both cases. Would want to see some kind of profiling comparison to validate this change. Even a number showing the calls avoided by the change. |
I did a little test with a slider with about 15 control points where a dragged the first control point in small circles and printed the number of times the The reason its still more than 1 recalculates per frame afterwards is I think because the |
Things like dragging the first slider control point move many control points in a single frame, and each time a single control point was moved it would trigger a recalculate of the whole slider, multiple times within a single frame.
I changed the logic in things that bind to changes in the path version to only refresh once per frame, so unnecessary refreshes are avoided.
Before:
https://github.com/ppy/osu/assets/17460441/1a7c780f-79f6-4f06-a314-c46bd069e54c
After:
https://github.com/ppy/osu/assets/17460441/d1bc9f6d-aba7-4f16-95f2-447b059574da
(The flashing is just a glitch with my ShareX recording)