Improve performance of displaying large number of activities

[dandelany]

Checked for duplicates

Yes - I've already checked

Alternatives considered

Yes - and alternatives don't suffice

Describe the feature request

When Aerie is showing a plan with thousands of activity directives, and the timeline is zoomed out so that most/all of these activities are displayed, the UI takes awhile to render, and any interactions which modify the view object become very slow. This is different from #959 because this is about activities/directives whereas #959 is for improving the line chart plot performance.

This is a complicated problem to solve, but we met with @AaronPlave @duranb and @jeffpamer today to discuss options for improving the performance here. It may take a few iterations & some design work before we're done with this, but here are some ideas to try from our meeting today:

• Band-aid fix for now: show heatmap instead of individual activities when too many are shown, to avoid breaking the UI?
• Figure out how not to re-render everything when the view object changes - difficult since Svelte does not have shouldComponentUpdate
• Don't re-pack activities while dragging them, only after releasing them
  • OR it may be worth deprecating drag-and-drop-to-edit as a feature if it's not used much (@mattdailis idea)
• Multi-frame chunked rendering or rendering in a worker (so UI is still usable before activities are done rendering)
• Clustering activities into a group of eg. "9 activities" instead of trying to show every one - this will likely be our long-term approach but needs some more design work/thought
• Smart redraw - being more granular about what you're painting so you don't redraw the entire canvas.

@AaronPlave had some more ideas too, so please add them to this ticket. Thanks!

[AaronPlave]

A few more potential optimizations:

• Pre-compute or cache expensive time computations like start_offset -> ms for directives and spans
• Consider redesigning directive icons to be less expensive to draw
• Optimize canvas context setting by drawing all text at in a single pass, could also be done for rects (chunked by color)

[lklyne]

@AaronPlave I have enough ideas that I think this could be ready for prototyping. Need to document a bit more and continue consolidating the best ideas, but created this ticket to track: #1140

[lklyne]

Goal

Show at a high level where things are happening and gives the user the ability to drill in to specific parts that are important. Provide some ability to collapse that would work well with our zoom functionality, giving more control over how much data is shown on the screen at once.

Concept

• Some sort of hierarchy or collapsable tree within the timeline. Show a heatmap when collapsed, with the ability to drill in to individual activities
• Automatic and swappable grouping. The approach i'm showing here is doing some automatic grouping based on the activity type name, but we're curious if it would be better to try and do something automatic here, versus driving the hierarchy based on some sort of customization (ie activity layers, tags, subsystem, etc)

Open questions

• What can someone group by? Does this happen in the row or in the timeline editor?
• What are the performance implications?
• Is there user control over subgrouping? Can the UI be configured like this: Level 1 use activity groups, level 2 group by tags, level 3 group by etc
• Do activity layer filters need to change at all for this? Or will they basically just act as a big filter on top of all of this?
• How can we give more visibility into how the filters have been applied? IE give the user clarity into what activity types fall in vs have been excluded
• How do we handle the vertical height of the canvas? Is this always set to auto and capped at a certain hight? Do we paginate long collapsed sections (ie include a show more button. if we paginate, what would that workflow look like?

[lklyne]

Since this will require several interconnected features and refactors to address, i've moved all of the suggestions and proposals into a Timeline UX improvements ticket. The second task list includes the many activities painpoint: https://github.com/NASA-AMMOS/aerie-ui/issues/1167