These used to work because there was a huge blocking load operation,
which is now more asynchronous.
Note that the change made in `SongSelect` is not required, but defensive
(feels it should have been doing this the whole time).
The only exception to the rule here was "when screen isn't active apply
without debounce" but I'm not sure we want this. It would cause a
stutter on returning to song select and I'm not even sure this is a
common scenario.
I'd rather remove it and see if someone finds an actual case where this
is an issue.
This reverts a portion of https://github.com/ppy/osu/pull/9539.
The rearrangement in `SongSelect` is required to get the initial filter
into `BeatmapCarousel` (and avoid the `FilterChanged` event firing,
causing a delayed/scheduled filter application).
I've been meaning to make the progress bar synchronise with the beat
rather than a continuous countdown, just to give the overlay a bit more
of a rhythmic feel.
Not completely happy with how this feels but I think it's a start?
I had to refactor how the break overlay works in the process. It no
longer creates transforms for all breaks ahead-of-time, which could be
argued as a better way of doing things. It's more dynamically able to
handle breaks now (maybe useful for the future, who knows).
I didn't really want to move the cursor in front of the HUD, but we face
a bit of an impossible scenario otherwise (it should definitely be in
front of the break overlay for visibility).
So I'll deal with it for now.
In testing I can't find a reason for this to exist. Blaming back shows
that it existed before we had `AllowTrackControl` and was likely being
used as a stop-gap measure to achieve the same thing. It's existed since
over 6 years ago.
Let's give removing it a try to fix some usability concerns?
Closes https://github.com/ppy/osu/issues/29563.