The beatmap listing content swap-out logic was already a source of
several problems, and several attempts of fixing it were made. But as it
turns out it was terminally broken in several aspects.
* The `BypassAutoSizeAxes` juggling was finicky and ugly, and didn't
really look much different than an instant fade. Therefore, all fade
durations and manipulations of `BypassAutoSizeAxes` are removed.
* The transform sequence juggling the `BypassAutoSizeAxes` manipulations
was enqueued on the content which is being in the process of fading
out. That was partially fixed in 25e38560, but as it turns out, that
only works if `lastContent` is one of the two placeholder drawables
(results not found / supporter required to use filter).
It would not work if `lastContent` is a
`ReverseChildIDFillFlowContainer` with cards from a previous search in
it.
The `lastContent == foundContent` check, last touched in a49a4329, is
terminally broken, as it would always be false. `foundContent` is
mutated when a new card load task is started in `onSearchFinished()`,
which is *before* the aforementioned check.
The code prior to a49a4329 was checking against the two static reused
placeholder drawables which was the correct check to apply, and this
commit reverts to using a variant of that check.
`BeatmapListingOverlay.addContentToPlaceholder()`, in order to make
transitions between different beatmap listing content (whether it is
actual cards, or placeholders for no beatmaps found/supporter-specific
filters chosen), would set `BypassAutoSizeAxes = Y` on content as it is
fading out, to make the transition smoother. The property in question
was supposed to be getting restored to `None` on the next show.
In testing scenarios, it sometimes turned out that this wasn't the case,
therefore making the placeholders effectively not show - while they
were present and fully opaque, they would be the only child of
an auto-sized container with `BypassAutoSizeAxes = Y`, so the parent
auto-sized to a zero height, which logically follows from the premise,
but is not what was desired.
This in turn was caused by the fact that the `BypassAutoSizeAxes = Y`
set was scheduled, and sometimes it would be scheduled in such a way
that the drawable would cease to be present on the next frame due to its
alpha being past the cutoff point of 0.0001. Therefore the scheduled set
would not execute until the *next* time the placeholder was shown,
therefore causing the bug.
Fix by ensuring that the placeholder drawables are always present if
their schedulers have any tasks enqueued, on top of the usual checks of
alpha and scale performed via the base implementation.
In theory this seemed like a good idea (and an optimisation in some
cases, due to lower fill rate), but in practice this leads to weird edge
cases.
This aims to do away with the operations on external drawables by
applying a dim to the area behind the `LoadingLayer` when required.
I went over each usage and ensured they look as good or better than
previously.
The specific bad usage here was the restoration of the colour on dispose
(if the `LoadingLayer` was disposed in a still-visible state).
I'm aware that the `BeatmapListingOverlay` will now dim completely during
load. I think this is fine for the time being.
