This is an issue as carousel panels manage their own animated state. If
they are marked as not-visible (done at a higher level, from filtering
or update pathways) but clicked while fading out, they will animate back
to a visible state but not be marked as visible.
No tests for this one as it's probably not worthwhile to test (and hard
to do so). Manual testing can be done with the following patch:
```diff
diff --git a/osu.Game/Screens/Select/BeatmapCarousel.cs
b/osu.Game/Screens/Select/BeatmapCarousel.cs
index c3d340ac61..3372242acc 100644
--- a/osu.Game/Screens/Select/BeatmapCarousel.cs
+++ b/osu.Game/Screens/Select/BeatmapCarousel.cs
@@ -255,7 +255,7 @@ private void
beatmapSetsChanged(IRealmCollection<BeatmapSetInfo> sender, ChangeS
}
foreach (int i in changes.NewModifiedIndices)
- UpdateBeatmapSet(sender[i].Detach());
+ Scheduler.AddDelayed(() =>
UpdateBeatmapSet(sender[i].Detach()), 100, true);
foreach (int i in changes.InsertedIndices)
UpdateBeatmapSet(sender[i].Detach());
```
- Enter gameplay and adjust beatmap offset then return to song select
and click the flashing panel.
OR
- Enter editor and save then return to song select and click the
flashing panel.
Closes https://github.com/ppy/osu/discussions/17171.
I kinda liked this flow, but from multiple reports from users it
definitely seems in the way. We can revisit after the new design is
applied to song select.
Note that this means the tooltips also don't display. If it is preferred
that they should (arguable from a UX perspective, since I'd expect to be
able to click at that point) then the issue can be addressed using a
slightly different path (a few more lines - nothing too complex).
Even with pooling applied, there are overheads involved with transforms
when quickly cycling through the carousel.
The main goal here is to reduce the transforms in cases the reuse is
still in the same state. Avoiding firing `FadeIn` and `FadeOut` are the
main areas of saving.
This addresses the number one performance concern with realm (when
entering song select). Previous logic was causing instantiation and
property reads of every score in the database due to the `AsEnumerable`
specfication.
The tests were relying on the `RulesetID` being set to 0 in the example
beatmap, even though the ruleset *instance* was set to ID 5.
This explicitly adds that 0 value to show intent, and also removes the
incorrect specification of 5 (which would cause the convert filter tests
to fail).
Also updates the filter code to use `OnlineID`, which is required in
realm changes.