That was a bad one... `ModelBackedDrawable` has a default of 0ms load delay, while previously the wrapper created for beatmap set cover used default 500ms, this change is bringing the load delay back, to avoid firing hundreds of web requests just when doing a quick long scroll on beatmap listing.
Applies two changes:
- Use `TransformImmediately` which achieves the same wanted transition behaviour without any issues.
- Move the transition behaviour override into `BeatmapListingSearchControl` in a nested subclass of `UpdateableBeatmapSetCover`.
Better suited there, I intiailly wanted the whole legacy interface to reside in `osu.Game.Rulesets.Osu` but it's required in `ConvertHitObjectParser` and that's in the main game project, so had to leave the interface as-is for now.
Further separates them from `IBeatSnapProvider`'s `SnapTime`, and groups them together more, to prevent confusion between the two interfaces.
Also changes the xmldoc of the reference time to that of `IBeatSnapProvider` for consistency.
Seems `EditorBeatmap` already implements a different kind of `SnapTime` from `IBeatSnapProvider`, so method names here aren't great.
This is very similar to what https://github.com/ppy/osu/pull/12558 is doing, so may need to do some duplicate resolution later, especially surrounding `ClosestBeatSnapDivisor`.
Worth noting that this change makes 1/7, 1/5, etc unsupported for now, as we now rely on `BindableBeatDivisor.VALID_DIVISORS`.
This is used in several places, and so should probably have a function rather than remaining as duplicated code.
Also applies this together with the previous commit to `BeatmapManagerWorkingBeatmap`.
This reverts commit f3faad74d5, reversing
changes made to 712e7bc7bf.
Several issues arose after migrating to 5.0, including, but possibly not
limited to, performance regressions in song select, as well as failures
when attempting to save beatmaps after metadata changes in the editor.
It turns out the SQLite API isn't smart enough to handle nullables
directly, so we need to help it out a bit.
Stops the following from being thrown:
```
System.InvalidOperationException: Value must be set.
at Microsoft.Data.Sqlite.SqliteParameter.Bind(sqlite3_stmt stmt) = 3
at
at Microsoft.Data.Sqlite.SqliteParameterCollection.Bind(sqlite3_stmt
stmt) = 3 at
at Microsoft.Data.Sqlite.SqliteCommand.ExecuteReader(CommandBehavior
behavior)
at Microsoft.Data.Sqlite.SqliteCommand.ExecuteReader()
at
osu.Game.Beatmaps.BeatmapManager.BeatmapOnlineLookupQueue.checkLocalCache(BeatmapSetInfo
set, BeatmapInfo beatmap) in
/Users/dean/Projects/osu/osu.Game/Beatmaps/BeatmapManager_BeatmapOnlineLookupQueue.cs:line
166 = 166
```
The previous code would run a calcaulation for the beatmap's own ruleset
if the current one failed. While this does make sense, with the current
way we use this component (and the implementation flow) it is quite unsafe.
The to the call on `.Result` in the `catch` block, this would 100%
deadlock due to the thread concurrency of the `ThreadedTaskScheduler`
being 1. Even if the nested run could be run inline (it should be), the
task scheduler won't even get to the point of checking whether this is
feasible due to it being saturated by the already running task.
I'm not sure if we still need this fallback lookup logic. After removing
it, it's feasible that 0 stars will be returned during the scenario that
previously caused a deadlock, but I don't necessarily think this is
incorrect. There may be another reason for this needing to exist which
I'm not aware of (diffcalc?) but if that's the case we may want to move
the try-catch handling to the point of usage.
To reproduce the deadlock scenario with 100% success (the repro
instructions in the linked issue aren't that simple and require some
patience and good timing), the main portion of the lookup can be changed
to randomly trigger a nested lookup:
```
if (RNG.NextSingle() > 0.5f)
return GetAsync(new
DifficultyCacheLookup(key.Beatmap, key.Beatmap.Ruleset,
key.OrderedMods)).Result;
else
return new StarDifficulty(attributes);
```
After switching beatmap once or twice, pausing debug and viewing the
state of threads should show exactly what is going on.
