feat: refactor timeline for better performance

[lcottercertinia]

Is your feature request related to a problem?

NOTE Since the below was written I have changed my mind, for better performance and to give head room for new features and larger log size support we have to go with Webgl. The best fit for 2d seems to be PixiJS.

I am keeping the below explainer because while Webgl should greatly improve performance the below techniques can still be implemented in our layout layer (which PIxiJs will not handle) to make this super fast.

When it comes to large logs or logs that produce a large number of visible items on the timeline performance of the zoom and pan suffers.

We need to speed up performance so that as we add new features such as text on nodes or a timeline overview / minimap, user experience of performance does not suffer especially on very large logs.

The first thing we need to do is split up logic into appropriate files, for example

• Tooltip
• Renderer
• Timeline scale / time markers
• Timeline
• Timeline of overview / minimap (future)

Just need to bear in mind that the web worker cannot import files but we may be able to work around it via bundling.

There are a number of options we could considered

• Use webgl, the api is far more low level and complex
• use ints when rendering rectangles and change zoom and pan to be done via scale and transform methods
• Draw to offscreen canvas.
• Use a web worker and/ or an (offscreen canvas, offscreen canvas) / offscreen canvas in a worker .
  • might need to figure out bundling web workers.
• Use a quad tree to split timeline sectors in 4, to speed up finding shapes that need to be drawn.
• zoom into the area of the chart with the most activity by default

When we zoom in performance improves, largely due to performance techniques we have already employed such as

• Virtualised timeline, similar to quad tree but still means we have to loop all nodes to determine which to draw.
• re render on change only e.g when zooming

Webgl

Webgl performs better than canvas, it might be a good idea to switch to it. The downside is this would be a large change and the api is more complex than canvas 2d it is more similar to game graphics rendering. The api is far more low level and complex but we can mitigate that by using one of the wrapper libraries such and Three.js, babylon.js or Pixi.js.

renderer

The renders will handle rendering of shapes, rendering in layers, zoom, pan, mouse position events etc. timeline, timeline marker, timeline overview will be supplied to the renderer for drawing and the layers will be handled in the order supplied by each class e.g

new timelineRenderer ({
  new timelineMarkers(),
  new timelineOverview()
});

Ensuring we have proper and clear encapsulation will allow us to more easily switch the drawing implantation if needed. For example we can have a canvas2d and a Webgl renderer and switch as needed.