lazy-load expensive beatmap attributes to show a UI sooner #12
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
what matters most to users is that a screen is shown as soon as possible after they click "visualize". This is an attempt to make that process faster by not loading a beatmap's hitobjects (and other attributes that rely on the hitobjects) in the initial rendering of the ui, and load them in a separate thread instead (the completion of which we wait for before actually visualizing anything, which was easy to do, since we already have that logic for the existing
process_sliders
thread).What I have here does work with no issues, which is why I'm pring it. The thing is, this adds a fair bit of complexity to the code and I'm not sure the speedup is all that significant (though it's a damn hard thing to test). I think I'm not going to merge this for now, but may change my mind in the future.
Note to future self: loading the beatmap itself (not even its hitobjs) from slider is likely to be expensive and should also be given the same lazy-load treatment for best results. Specifically this code: