-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve entropy recalculations #1879
Conversation
2c81abc
to
4588d6c
Compare
Updated to fix a bug when viewing narratives and also fix linting errors |
4588d6c
to
281bc90
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I played around with the groups/blab/ncov-orf8ko/WA/20k
dataset and definitely see improvements in responsiveness!
I only left non-blocking comments. In general, I find the split of management of entropy data between the Redux actions and Entropy component a bit weird. It feels like the Redux actions should trigger that entropy data updates appropriately and the Entropy component should just remain a consumer of that data.
65a982c
to
446d5c9
Compare
by not recalculating data on the leading edge of the debounced recalculation action. For big trees (which take >500ms of time to redraw) the main thread is still blocked for roughly the same amount of time, but the tree is redrawn faster. For small trees which redraw quicker than that the entropy doesn't update until the debounce 500ms timeout is reached, resulting in slightly odd behaviour. (Reducing this timout also results in less-than-ideal behaviour as (e.g.) dragging the date range of a tree results in interruptions while the entropy calcs run which is worse IMO.)
Improves the performance of most interactions in Auspice when the `<Entropy>` panel's not displayed by not constantly updating the entropy calculations. The downside is when the panel's toggled on things are a little slower as we recalculate at that point. Note that the Entropy panel should never be rendered with invalid / stale / uncomputed data. Any action which results in the panel being shown is responsible for ensuring the underlying data is updated as appropriate.
Use an intersection observer to detect when the entropy panel is visible on the screen (viewport). When it's offscreen we don't update entropy data (an expensive calculation). When it comes back onscreen we recalculate the entropy data if it has become stale. This results in slightly strange behaviour when the entropy panel will be shown with no bars and they'll be drawn after a slight delay (while the data's recalculated). The wins are much improved performance when the entropy panel is not on screen (which is common).
3799a98
to
5543a86
Compare
The bug arose because window-resizes trigger a complete re-render of the entropy panel's SVG and this didn't correctly handle an edge case where the entropy data was stale (a concept introduced in #1879). For specific steps to reproduce see <#1895 (comment)> Closes #1895
Improves the general speed of Auspice when the Entropy panel is not displayed (either toggled off or off-screen). The downside is a small amount of time where there's a blank entropy panel when it scrolls back into view after a state change which requires the entropy data to be recalculated. (The win is that we skip these recalculations so everything else is faster.)
Eyes on the behaviour changes in this PR would be very welcome!
There's more we can do here, but I'll leave the following for subsequent PRs:
requestIdleCallback
APIRelated to #1878