1
0
mirror of https://github.com/ppy/osu.git synced 2024-12-24 23:12:54 +08:00
Commit Graph

21 Commits

Author SHA1 Message Date
Bartłomiej Dach
f13ca28d5e
Fix performance overhead from ternary state bindable callbacks when selection is changing
Closes https://github.com/ppy/osu/issues/28369.

The reporter of the issue was incorrect; it's not the beat snap grid
that is causing the problem, it's something far stupider than that.

When the current selection changes,
`EditorSelectionHandler.UpdateTernaryStates()` is supposed to update the
state of ternary bindables to reflect the reality of the current
selection. This in turn will fire bindable change callbacks for said
ternary toggles, which heavily use `EditorBeatmap.PerformOnSelection()`.

The thing about that method is that it will attempt to check whether any
changes were actually made to avoid producing empty undo states, *but*
to do this, it must *serialise out the entire beatmap to a stream* and
then *binary equality check that* to determine whether any changes were
actually made:

	7b14c77e43/osu.Game/Screens/Edit/EditorChangeHandler.cs (L65-L69)

As goes without saying, this is very expensive and unnecessary, which
leads to stuff like keeping a selection box active while a taiko beatmap
is playing under it dog slow. So to attempt to mitigate that, add
precondition checks to every single ternary callback of this sort to
avoid this serialisation overhead.

And yes, those precondition checks use linq, and that is *still* faster
than not having them.
2024-06-04 10:32:12 +02:00
Dean Herbert
0ab0c52ad5 Automated pass 2023-06-24 01:00:03 +09:00
Dan Balasescu
7bc8908ca9 Partial everything 2022-11-27 00:00:27 +09:00
Dan Balasescu
f8830c6850 Automated #nullable processing 2022-06-17 16:37:17 +09:00
Dean Herbert
4c9d72e62a Ensure EditorBeatmap.Update is called inside PerformOnSelection calls 2021-05-23 21:22:35 +09:00
Dean Herbert
df5970fab4 Create base implementations of the two most common TernaryStateMenuItems 2021-05-20 19:34:53 +09:00
Dean Herbert
4c9e94da2b Move context menu logic to base class 2021-04-28 13:43:16 +09:00
Dean Herbert
f2e56bd306 Refactor editor selection/blueprint components to be generic 2021-04-27 19:01:29 +09:00
Dean Herbert
cd1c1bf534 Centralise cases of performing actions on the current selection
By moving this to a central location, we can avoid invoking the
EditorChangeHandler when there is no selection made. This helps
alleviate the issue pointed out in
https://github.com/ppy/osu/issues/11901, but not fix it completely.
2021-02-26 14:15:13 +09:00
Bartłomiej Dach
5af1ac1b53 Rename TaikoStrong{-> able}HitObject 2020-12-14 21:46:02 +01:00
Bartłomiej Dach
f74567e8eb Introduce base class for hitobjects that can be strong 2020-12-13 12:36:39 +01:00
Dean Herbert
681e88af40
Merge branch 'master' into editor-fix-button-states-after-paste 2020-10-09 20:51:09 +09:00
Dan Balasescu
ecfb7e94c5
Merge branch 'master' into fix-editor-batch-handling 2020-10-09 20:06:06 +09:00
Dean Herbert
3838f405dd Fix missed usages 2020-10-09 18:50:05 +09:00
Dean Herbert
c9f069d7ed Fix taiko's HitObjectComposer not allowing movement o
f selected hitobjects
2020-10-08 18:17:57 +09:00
Dean Herbert
afed832b19 Tidy up EditorBeatmap slightly 2020-10-08 18:06:49 +09:00
Dean Herbert
38babf3de5 Update usages of ChangeHandler to EditorBeatmap where relevant 2020-10-08 18:04:07 +09:00
Dean Herbert
1aa8b400d4 Avoid unnecessary object updates from SelectionHandlers 2020-09-28 15:33:49 +09:00
Dean Herbert
727ab98d22 Update taiko selection handler with new logic 2020-09-25 15:32:45 +09:00
Dean Herbert
487fc2a2c6 Add missing change handler scopings to taiko context menu operations 2020-09-23 16:58:22 +09:00
Dean Herbert
da289c474e Split files out 2020-05-29 16:45:47 +09:00