Make storyboard rendering async/threaded?

[p0358]

It seems that some storyboards being enabled can cripple the performance severely, such as dropping from 480 fps all the way to 40-ish.

My question is: with all the multi-threading going on, why wouldn't osu!lazer render the storyboards with all its effects in a separate thread, and in the drawing/update threads only grab the last frame/texture from that thread and present it? This way the main drawing would've been perfectly smooth and the storyboard lagging in the background wouldn't affect the gameplay.

I think such a thread should then be limited at most to display's refresh rate, as drawing more often would've been a waste there. Sounds straightforward enough in principle I think, there are games out there that do something similar for drawing the UI if it's webbrowser-based etc. I know I could just disable storyboards in the game like many people do, but they're cool and they since they already exist in the game, it should be a goal to have them perform okay, without gameplay-screwing fps drops :/

Of course I will give a link to the beatmap that have prompted me to create this post: https://osu.ppy.sh/beatmapsets/470977

As you can see, just peeking to the problematic purple area at the end of the song causes the fps to immediately drop, pressing play would've caused it to further dip to ~40 fps... But also even outside of this critical area, there are many more that randomly drop the fps to 120-220, which is much less noticeable but still not the unbothered baseline of 480...

But frankly I don't know what the colors on the graph mean, nor whether the storyboard rendering is done on the CPU or GPU. If it's a GPU and it's a lot of draw calls, then shared textures would probably be a much better bet than something like a command queue, idk.

EDIT: Okay I have realized that I can hold Ctrl to see the values of the colors:

Right, this makes sense, the update thread does a lot of CPU work, and then that causes the render thread to sleep a lot just waiting for it. Also noticed that I don't need to press play to dip the fps, it's enough to be moving the mouse around vs keeping it idle for a screenshot, and it also drops to these ~40 fps.

[peppy]

Making it asynchronous is probably higher effort than rewriting the slow parts.

A simpler solution may be to limit the frame rate of storyboard playback when it can't keep up. This could be done in 5 minutes.
Won't work well because every frame is high enough frame time that this would just lead to unstable frames.

[p0358]

Not sure how much more it could be limited though if it can already dip to 40 fps, and whether that'd save the player experience enough and on time. But maybe still worth trying if that could easily improve the situation in the meantime.

I'm just not sure if slow parts could be easily improved, there's noticeable dips even when there isn't as much going on, while otherwise there isn't much that could decrease the performance from 900+ fps when limit isn't capped.

And technically something like a video encoder does its accelerated decoding separately and just copies the frames, it'd make sense for storyboard renderer to have similar philosophy and then it'd never drop a single fps from it (assuming no general PC overload)