Skip to content
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

[PARKED] New canvas render methods for node layout #317

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

admataz
Copy link
Contributor

@admataz admataz commented Mar 25, 2019

This is a work in progress

  • renames files and modules to remove SVG assumption
  • adds Canvas as an alternate (not necessary replacement) for SVG - will open possibility to keep SVG where it desired
  • renders layout with canvas
  • renders node lines and bubbles with canvas
  • renders shortcut nodes with canvas
  • renders labels in canvas [WIP: currently working through text measurement in canvas
  • establish a method to maintain styles across SVG and canvas [WIP: as we go - we'll do our best]
  • add interaction layer to Canvas rendering
    • '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
    • tracking rendering of bubbles for positioning of the hoverBox
  • 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 ??
  • 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 admataz changed the title WIP: New canvas render methods for node layout New canvas render methods for node layout Mar 27, 2019
@admataz
Copy link
Contributor Author

admataz commented Mar 27, 2019

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
3CD568EA-EAD7-47A9-B211-4938BFCE37D0

and I get this:
Pasted image at 2019-03-26, 4:09 PM
155365C5-B761-43B2-86DB-F7E132FF52AC

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

@goto-bus-stop goto-bus-stop changed the title New canvas render methods for node layout [PARKED] New canvas render methods for node layout Nov 1, 2019
@jasnell jasnell changed the base branch from master to main August 21, 2020 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant