Entering song select has seen a hit since the new renderer
implementations. The underlying cause is large numbers of vertex buffer
uploads (the counter hits >200k for me during the transition).
Song select is in the process of being redesigned, and we are probably
going to make improvements to the renderer to alleviate this, but in the
mean time we can greatly improve the user experience by reducing how
long the initial fade in delays take on panels.
Visually this doesn't look too jarring, and gives a more immediate
feeling when scrolling. It's also more feasible to load elements sooner
with https://github.com/ppy/osu/pull/23809 applied.
This is an effort to improve general performance at song select. At
least on the metal renderer, I can notice very high draw frame overheads
related to texture uploads.
By reducing the size of the texture uploads to roughly match what is
actually being displayed on screen (using a relatively inexpensive crop
operation), we can bastly reduce stuttering both during initial load and
carousel scroll.
You might ask if it's safe to disable mipmapping, but I've tested with
lower resolutions and bilinear filtering seems to handle just fine.
Bilinear without mipmaps only falls apart when you scale below 50% and
we're not going too far past that at minimum game scale, if at all.
The handling of cleanup is performed only the `Item_Set` method. This
was already correctly called for `DrawableCarouselBeatmapSet`, but not
for the class in question here.
This would cause runaway memory usage at song select when opening many
beatmaps to show their difficulties. For simplicity, we don't yet pool
these (and generate the drawables each time a set is opened) which isn't
great but likely will be improved upon when we update the visual /
filtering of the carousel. But this simplicity caused the memory usage
to blow out until exiting back to the main menu when cleanup would
finally occur.
Reproduction steps:
1. Go to song select
2. Open beatmap listing
3. Import a beatmap that would fit the current filter criteria
4. The count of visible beatmaps does not change
Fixed by updating the count on `BeatmapSetsChanged` too.
From a user's perspective, changing a sort / order mode shouldn't filter
away results, but we were doing this.
In terms of UX expectations, in stable this kind of scenario would
results in a group being added to the end of son select with "Not
ranked" or "Unknown". I think we should aim to match this eventually.
