Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
graph_visualization_technology_choice [2016/03/16 15:50]
mcgee
graph_visualization_technology_choice [2016/03/16 16:05] (current)
mcgee
Line 9: Line 9:
 For the front end graph visualization,​ using pure d3.js has some disadvantages,​ particularly as once graphs become too large for SVG rendering, for example much extra development is required to duplicate much of the SVG style interaction with graph elements. For the front end graph visualization,​ using pure d3.js has some disadvantages,​ particularly as once graphs become too large for SVG rendering, for example much extra development is required to duplicate much of the SVG style interaction with graph elements.
  
-In terms of speed of rendering SVG is slowest , canvas is faster and WebGL is fastest. However the benefits to using WebGL are can sometime ​only be gained with a large change of architecture. Simple transformations like panning and zooming may be  much quicker, but more complex operations that require regular updates from the CPU can mean that a WebGL implementation is not much faster than a canvas one (if at all). For a task such as graph layout, the GPU would certainly improves speeds however getting the calculation there is still difficult. There is no CUDA equivalent of WebGL at the moment. WebCL is still not ready, a may not be supported by many browsers. The most viable option is compute shaders, but they are not part of the implemented WebGL specification yet. General purpose GPU approaches exist , but due to their inflexibility and difficulty of implementation are not suitable for our purposes.+In terms of speed of rendering SVG is slowest , canvas is faster and WebGL is fastest. However the benefits to using WebGL can sometimes ​only be gained with a large change of architecture. Simple transformations like panning and zooming may be  much quicker, but more complex operations that require regular updates from the CPU can mean that a WebGL implementation is not much faster than a canvas one (if at all). For a task such as graph layout, the GPU would certainly improves speeds however getting the calculation there is still difficult. There is no CUDA equivalent of WebGL at the moment. WebCL is still not ready, a may not be supported by many browsers. The most viable option is compute shaders, but they are not part of the implemented WebGL specification yet. General purpose GPU approaches exist, but due to their inflexibility and difficulty of implementation are not suitable for our purposes.
  
 Sigma.js uses WebGL for rendering (when available) and supports all of the interesting functionalities that make SVG such a benefit, and as such would be an excellent choice as a starting point for graph viz at the front end. We can extend the functionality offered in terms of layout and analytics etc by providing access to other libraries via the back-end. Sigma.js uses WebGL for rendering (when available) and supports all of the interesting functionalities that make SVG such a benefit, and as such would be an excellent choice as a starting point for graph viz at the front end. We can extend the functionality offered in terms of layout and analytics etc by providing access to other libraries via the back-end.