[PARKED] New canvas render methods for node layout

[admataz]

This is a work in progress

• [x] renames files and modules to remove SVG assumption
• [x] adds Canvas as an alternate (not necessary replacement) for SVG - will open possibility to keep SVG where it desired
• [x] renders layout with canvas
• [x] renders node lines and bubbles with canvas
• [x] renders shortcut nodes with canvas
• [x] renders labels in canvas [WIP: currently working through text measurement in canvas
• [x] establish a method to maintain styles across SVG and canvas [WIP: as we go - we'll do our best]
• [x] add interaction layer to Canvas rendering
  • [x] 'shadow canvas' idea as explored in previous versions of area chart - we don't have access here to the exact data mapping like the area chart - so this is probably the only way to acheive this
  • [x] tracking rendering of bubbles for positioning of the hoverBox
• [x] add animation to Canvas rendering (basic fade only - no morph transition of nodes)
• [ ] finer detail around styling from CSS definitions - e.g. opacity on fill colours
• [ ] finer detail around mouse interaction - hover and highlight
• [ ] reproduce the tweened/morph transition animation for sublayouts ??
• [x] method to switch on/off svg rendering (based on conditions like number of nodes?)
• [ ] abstract the methods to a generic use case - for future D3 in SVG/Canvas (nice to have)

ongoing notes and thoughts:

SVG is deeply embedded in the way this has been initially authored. I have decided to maintain the SVG rendering capability, and use the D3 node creation as a data-binding layer that is also used in the canvas rendering methods. This is a common pattern in D3 for canvas.

I am also looking for opportunities to be more declarative with the rendering methods - so the relevant rendering data model for the visualisation state can be defined separately and actual rendering is a more abstracted function call - to be called on load/animation frame/ interaction etc. in a 'reactive' way. This probably will require more architectural thinking and a rework of the current bubbleprof frontend.

Questions about efficiency of canvas animation redraws vs native CSS animations. Also managing modularity of canvas 'elements' - where this is built in to DOM nodes in SVG.

[admataz]

I've removed the WIP label here and happy for this to be reviewed - after yesterday's call we agreed not to sweat the minor details around styling - and to enable a auto switch for canvas rendering mode when there are more than 400 connections in the diagram - which I have done. As mentioned on Slack, in analysing the heavy test example (1400+ nodes) - I found the following: (repeating here)

TL;DR: I think we're good to go with canvas - its a definite improvement in the UX, once the diagram has loaded - there are still major issues with memory and time with the layout that are not to do with rendering - and I will investigate these in another branch,

Initial comparisons: the canvas version is a definite winner in terms of janky-ness in the UI - in the SVG version switching tabs causes a flash of blank screen/reload, and the hoverbox struggles to keep up with the mouse movement when moving over the area chart - where in the canvas version that is smooth. Both still take a long time to load - mostly spend in generateLayout (about 18s) and the rendering of the nodes is about 2s faster in canvas (edited) neither version copes very will with this: Pasted image at 2019-03-26, 4:08 PM

and I get this: Pasted image at 2019-03-26, 4:09 PM

I’ll dig a little deeper - but it seems more gains could be made from improving the layout code at this point (if possible)