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.
It turns out there's some quite convoluted scheduling / order of
execution requirements of ModSelectOverlay and ModSection. Applying
scheduling causes a runaway condition ending in zero frames after many
mod button changes.
I wanted to avoid rewriting the whole component, so have just moved the
schedule to guard against the part where drawables are actually changed.
There are 3 modes: enabled, limited, and disabled.
The limited mode hides identifiable information such as username, rank, and
(if participating in one) multiplayer lobby name.
It turns out that the changelog code was semi-intentionally relying on
the request to get release streams to be slow to initially show the
listing of all streams.
Locally suppress the base tab control logic to fix this.
Scheduling the entire API state change callback caused the scheduled
hide to fire the first time the user attempted to display the account
creation overlay after a logout, because the drawable wasn't present
before that (so its scheduler wasn't running).
It is not theoretically safe to run `Hide()` unscheduled at its present
call site (as the value change callbacks are fired on the background
API thread). This could also be fixed by setting `AlwaysPresent = true`,
but that's a pretty ugly and unperformant change to make in general.
The callbacks are scheduled to the API thread, but hooked up in BDL
load. This causes a potential case of cross-thread collection
enumeration.
I've tested and it seems like the schedule logic should be fine for
short term. Longer term, we probably want to re-think how this works so
background operations aren't performed on the `DrawableChannel` in the
first place (chat shouldn't have an overhead like this when not
visible).
Closes#11231.
