Decide lib for canvas/webgl renderer

[maxkfranz]

This will give us better performance, and it is in line with our initial plan to use SVG as a starting point due to its good cross-browser compatibility and ease of development.

Libraries we could use to make development with canvas easier:

• cakejs http://code.google.com/p/cakejs/
• invaklib http://lib.ivank.net/
  • Flash-like API
• GLGE http://www.glge.org/
• EaselJS http://createjs.com/#!/EaselJS
  • Flash-like API
• KineticJS http://www.kineticjs.com/
  • Nice API for handling sprites
  • good performance
• ProcessingJS http://processingjs.org/
  • WebGL :)
  • really low level API :(
• libcanvas https://github.com/theshock/libcanvas
• probably more options out there

[ghost]

The current plan seems to be to use WebGL directly. The size of the minified Three.js library was a bit large (400kb) and this allows for some optimization such as reducing vector dimensions in shader calculations and finer control over how data is sent to the GPU. The current plan for text is to draw directly using the canvas object's 2D context, using the filltext() methods. This was found to be faster than texture-mapped text in previous tests and was much faster than polygon-based fonts tested with Three.js.

[maxkfranz]

http://coding.smashingmagazine.com/2012/02/22/web-drawing-throwdown-paper-processing-raphael/

[maxkfranz]

Libraries have been found to add significant computational overhead in addition to a not insignificant number of kB. Thus, it does not make sense to use a library for drawing. We should use canvas or WebGL directly.

WebGL

• complicated API
  • requires shaders to get good performance (requires a dedicated resource for renderer development)
  • requires a lot of code to do simple drawing operations
  • our code will have more kB
• performance described as "one step ahead of canvas"
• doesn't currently work on touch devices; probably will have support (soon?)
• future uncertain (non-W3C standard) -- Microsoft have refused to support it etc.
• won't work without a compatible graphics card (Chrome has a software renderer, but it's unsure whether other browsers will follow suit)

Canvas

• simple API
  • other devs can contribute
  • operations are high level so we can focus on behaviour
  • our code will have less kB
• slows down at 10,000 nodes and 20,000 edges (approx.?)
• works on touch devices
• lots of vendors -- including Microsoft -- have pledged support for canvas
  • a lot of work is going into making canvas faster in desktop and mobile browsers

In my opinion, we should go with canvas. Performance will constantly improve as browsers improve, and canvas has a guarantee of compatibility whereas we would be making a risky bet on WebGL. Canvas will give us significantly better performance than SVG, anyway.

Can we afford the development time required to maintain a WebGL renderer? It will require a resource well-versed in OpenGL/WebGL who can devote at least one day of work a week, most likely.

WebGL will also make it much more difficult for other people to contribute to the project. Considering that one of the motivations for the HTML5 version is to make it much easier for external resources to contribute to the project, I would advise against WebGL.

[djcas9]

How are you getting 10k nodes / 20edges. I am having problems just getting it to 2k or 1,500k currently. Any tips?

[maxkfranz]

Please refer to the performance notes in the docs. Performance is mostly based on your code and the options you choose.

[djcas9]

Sorry, should have clarified I did that. My perf issues seem to come from .add / Is there a reason it creates another Collection object vs just adding it to cy._private.elements? Is there a way around the cost of creating an $$.Elelemt object for each node and edge?

[maxkfranz]

I wouldn't take those numbers too literally. They correspond to early estimates only relevant to a particular part of rendering, and make a bunch of assumptions. Of course, performance also will differ depending on machine, OS, browser, etc.

There is no way around creating an Element, and the Collection shouldn't add much overhead. However, you could experience other, rendering-related issues if you add many elements in many calls. You will likely have better perceived performance by adding multiple elements in one call rather than several in a row.

There are batch APIs in 2.3 that make it easier to make lots of little calls together in groups as though they were a single "operation". There are also a lot of unrelated changes that provide overall improved performance.

Finally, please create new Github issues for separate questions/tickets. If you have an issue specific to your particular usecase, it's better to have a separate starting point to isolate the issue.

Thanks for your feedback!