In general we're doing things correctly so the realm file shouldn't
expand (unless mass deletions are made from it), but this is a nice way
to manually confirm the behaviour.
Sometimes if using realm studio with osu! running, for instance, the
realm file size can blow out of proportion. This will recover from such
cases.
Note that calling `RealmFactory.Compact` itself is not enough, as it
will fail unless all instances of the realm have been closed.
While displaying replays, the colour of the toolbox toggle button would
not match the actual state of the rest of the toolbox, i.e. both buttons
would be white, even though the "playback settings" section was expanded
and as such should have a yellow toggle button.
In the case of the replay player, the failure scenario was as follows:
1. `SettingsToolboxGroup` calls `updateExpanded()` in its BDL to update
the initial state of the toolbox, including the toggle button
colour, by adding a colour fade transform.
2. An ancestor of both the toolbox groups - `PlayerSettingsOverlay`,
which is a `VisibilityContainer` - calls `FinishTransforms(true)` in
its `LoadCompleteAsync()`, therefore instantly applying the colour
from point (1) to the toggle button instantly.
3. However, `IconButton` inherits from `OsuAnimatedButton`. And
`OsuAnimatedButton` changes its colour in `LoadComplete()`, therefore
undoing the instant application from point (2).
This conjunction of circumstances is instrumental to reproducing the
bug, because if the `FinishTransforms(true)` call wasn't there, point
(3) wouldn't matter - the transform would get applied at some
indeterminate point in the future, ignoring the write from
`OsuAnimatedButton`.
As for the fix, move the `updateExpanded()` call in
`SettingsToolboxGroup` to `LoadComplete()` to avoid the above
unfortunate order. Applying initial visual state in `LoadComplete()` is
the idiomatic style of doing things these days anyhow.
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.
During profile, it was found that the `Completed` delegate was
incorrectly also capturing `lastTrack`, leading to an unexpected
reference chain that led to a memory leak over a long period of time.
This solves the issue by moving the delegate construction to its own
method, where it won't capture the other variables.
