* Rename to `sortUserSkins` to convey meaning better.
* Sort in-place instead of slicing the list.
* Change to `void` to avoid misleading users that the method returns
a new list instance.
* Fix typo in comment.
The previous code was very brittle - it was not always updating
properly, and seems to have worked either by a carefully crafted set of
circumstances, or just plain coincidence.
Having this be a get-only property avoids potential error in the future
caused by not updating the index properly, at the expense of an added
linear lookup.
Culls another non-thread-safe mutation of the `Playing` bindable.
It seems to be a weird vestige from an earlier revision of the old
"direct" panel, which relied on `DisposeOnDeathRemoval` to finish track
playback (and then was removed in
6c150c9ed7). The play button is no longer
responsible for managing preview track lifetime anyway;
`PreviewTrackManager`'s method are intended for that.
Revealed by the framework-side transform thread safety checks. `Stopped`
is even annotated as not being thread-safe (but was annotated as such
long after the class's nascence).
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.
