For wheel input with precision, we still prefer exact tracking for now.
May change this in the future based on feedback from mappers, but it
makes little sense to do non-snapped scrolling when input is coming from
a non-precise source.
`onLoadRequested()` always released the `readyClickOperation` ongoing
operation, without checking whether it actually needs to/should (it
should only do so if the action initiating the operation was starting
the game by the host). This would crash all other consumers, who already
released the operation when their ready-up operation completed server
side.
To resolve, relax the constraint such that the operation can be ended
multiple times in any order. At the end of the day the thing that
matters is that the operation is done and the ready button is unblocked.
It turns out this polling was necessary to get extra data that isn't
included in the main listing request. It was removed deemed useless, and
in order to fix the order of rooms changing when selecting a room.
Weirdly, I can't reproduce this happening any more, and on close
inspection of the code can't see how it could happen in the first place.
For now, let's revert this change and iterate from there, if/when the
same issue arises again.
I've discussed avoiding this second poll by potentially including more
data (just `user_id`s?) in the main listing request, but not 100% sure
on this - even if the returned data is minimal it's an extra join
server-side, which could cause performance issues for large numbers of
rooms.
Finishing an operation started via
`OngoingOperationTracker.BeginOperation()` was risky in cases where the
operation ended at a callback on another thread (which, in the case of
multiplayer, is *most* cases). In particular, if any consumer registered
a callback that mutates transforms when the operation ends, it would
result in crashes after the framework-side safety checks.
Rework `OngoingOperationTracker` into an always-present component
residing in the drawable hierarchy, and ensure that the
`operationInProgress` bindable is always updated on the update thread.
This way consumers don't have to add local schedules in multiple places.
Fixes a potential crash when moving from main menu to editor after
having previously opened the login settings overlay. Setting the
activity in BDL as done before is unsafe, as that set can trigger value
change callbacks, which in turn can trigger adding transforms, which
should always be done on the update thread.
Semantically it also makes sense, as the user activity should change
once the screen they're moving to has actually loaded and displayed to
the user.
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.
Looks like this was just copy-paste without any thought into whether it
should exist. It really shouldn't exist.
This is a thing for the playlists system because the *whole system*
there relies on polling the web API to get updated information. In the
case of mutliplayer, we hand off all communications to the realtime
server at the point of joining the rooms.
The argument that this was there to do faster polling on the selection
isn't valid since the polling times were the same for both cases.
Closes#11348.
It needs to be explicitly stated that the users in this list are related
to the *joined* room. Especially since it's sharing its variable name
with `SpectatorStreamingClient` where it has the opposite meaning (is a
list of *globally* playing players).
