svg

[forresto]

prototyping: http://forresto.github.io/prototyping/react/ ~ forresto/dataflow-prototyping#2

React's virtual dom will make it easy to render svg on the server, if we ever need that for previews, etc: https://github.com/facebook/react-page/

[forresto]

fontawesome + svg: http://stackoverflow.com/a/19892061/592125

g.append('text')
  .attr('text-anchor', 'middle')
  .attr('dominant-baseline', 'central')
  .attr('font-family', 'FontAwesome')
  .attr('font-size', '20px')
  .text(function(d) { return ICON_UNICODE[d.nodeType]; });

The attrs could be in css. The important part is the ICON_UNICODE object.

a = fontawesome yml -> to json -> this js:

var o = {}; 
a.icons.forEach(function (icon) {
  o[icon.id] = icon.unicode;
});
copy( JSON.stringify(o) );

output: https://gist.github.com/forresto/8254791

[forresto]

Added icons and zoom breakpoints to change design: http://forresto.github.io/prototyping/react/

SVG certainly makes some things quite nice. Aligning the icon in the node, for example. Also, circles.

Unfortunately transform changes, which make zooming and infinite canvas really easy, always cause expensive layout / paint:

70ms zoom, 40ms pan 👎 (but IE 9 does accelerated svg??? )

Even though it makes the framerate slow, it is steady, so it doesn't feel super janky. But it doesn't feel like 60fps.

Could maybe work around by using transform3d on the parent div layer while the movement is happening, then swapping that to the transform on the SVG g at the end of the movement. Like what we have now. Would lose the vector feel while zooming though.

[forresto]

Figured out that svg transform is much faster without css, as that's what's forcing the purple layout bars above. Here's a similar demo, fast without css. I don't think it is worth ditching CSS now, though (I went down that road a bit). If we did that (converting all styling to attributes, passing styles through) it would be almost as much work to go all-2d canvas.

Dragging a node works, is fast:

Most of the frame budget is yellow, because React forces anything that affects stuff elsewhere in the tree (moving node changes its edges) to be rerendered by the common ancestor. In this case, it seems like it would be faster to have a listener on the edge (like we have in Polymer). OTOH, the pattern is clean.

[forresto]

Unexpected: Safari and Firefox feel way faster than Chrome with zooming and panning. There must be a bug causing all those purple layout invalidations.

[plievone]

Unexpected: Safari and Firefox feel way faster than Chrome with zooming and panning. There must be a bug causing all those purple layout invalidations.

Very interesting experiments! There might be an issue in Chrome where simply listening for wheel events disables some rendering optimizations. If you want to explore it further, one can build the current React master that doesn't listen for all events by default, but only the needed ones, and then compare performance if you declare an onWheel handler or not.

[forresto]

For the layout invalidations I made a reduced case and bug report to see what the Chromium folks say.