Create a component for headlessly processing replays#36943
Create a component for headlessly processing replays#36943LiquidPL wants to merge 6 commits intoppy:masterfrom
Conversation
|
|
||
| AddStep("import replay", () => | ||
| { | ||
| using (var replayStream = TestResources.OpenResource($"Replays/osu-renatus-replay-failed.osr")) |
| }); | ||
| AddStep("create player", () => | ||
| { | ||
| // Component isn't hidden in tests to allow for visually checking if everything works correctly. |
There was a problem hiding this comment.
I can't see anything running the test though
There was a problem hiding this comment.
I forgot to remove this thing where I was trying to see if preventing things from rendering would improve the playback speed (it didn't). f753901
|
Profiling shows some room for improvement.
But all in all, I don't think these are blockers. We can improve performance as we go. It's already in a usable place IMO, as long as it works well and can be cancelled. |
That's weird, it's been always using argon for me (at least in the test browser, not when actually running headless). It's definitely a good idea to enforce a skin here though, even if it's not one that's optimized for it yet.
This is something I'm not fully confident about. Given that what's done currently is just seeking to the end of the replay and waiting for the playback to complete, I don't have a simple way to hook in and interrupt that process. However, since this component isn't meant to be reused after playback starts, I suppose it's fine if whoever owns this just disposes it whenever there's a need to cancel? |
| public void Start() | ||
| { | ||
| if (!IsLoaded) | ||
| return; | ||
|
|
||
| double? lastFrameTime = score.Replay.Frames.LastOrDefault()?.Time; | ||
|
|
||
| if (lastFrameTime == null) | ||
| return; | ||
|
|
||
| clock.Seek(lastFrameTime.Value); | ||
| } |
There was a problem hiding this comment.
Given what I said in the comment earlier, I suppose this should just run in LoadComplete() and not be exposed as a public method.
There was a problem hiding this comment.
I can't think of a situation where this wouldn't be called immediately.
Expire the drawable? Or just forcefully remove it. The important part is that there's a simple API to make all this happen which hopefully isn't manual drawable lifetime management every time this is used.
I only ran headless, and couldn't see in test browser anyway. |
This comment was marked as spam.
This comment was marked as spam.
As [per comment](#36943 (comment)). Unfortunately I'm not able to reproduce such a big impact of triangles using linked pr (or at all really). In my case usage was low in the first place and went from 0.9% to 0.6% with this pr, so outside benchmarking would be great Improvement list: * No more sorted list. Basic list is being used which is sorted once after all the triangles added. * Out-of-bounds triangles are reused rather than removed and re-added. * On `Reset` if `AimCount` stays the same, all triangles are reused instead of being cleared and re-added.
3 participants
Meant to be used on the results screen to automatically process the replay to obtain hit event data for the statistics panel.
RFC. This is kinda rough, what I've done here is effectively taking the essential bits from
Player(DrawableRuleset,ScoreProcessor,HealthProcessor) that are needed to properly play through and judge a beatmap (and probably commiting some cardinal sins of threading while at it). This isn't currently plugged in anywhere, as I wanted to ensure this is the right direction to take this first.I suppose there's no way around having it process and draw all the hitobjects, even if the player components itself is not shown. I was wondering if there's a way to speed this process up somehow, since at least for me processing ~3 minute beatmap would take around 2-3 seconds, which is unfortunate since if this were faster maybe it'd be possible to quickly run this when the user is entering the statistics screen.