I understand the differences between <canvas> and SVG, and the pros and cons of both. I'm creating a hierarchical diagram, whose nodes and connections a user can manipulate through event handling. The clear winner would normally be SVG, as there's a true DOM I can use.
However, I've heard claims that <canvas> is a contender for such an application with the proper scene graph (DOM) library. I can't find consensus on what the go-to scene graph library for <canvas> is (for SVG, it's Raphael). Can someone point me in the right direction, or are these libraries too immature to supersede SVG for complex DOM manipulation?
Cake (old page) is a library for that. I've used it and it worked quite well.
Sounds like you might like to check out d3.js (still SVG-based, but does allow large datasets and has good performance).
Related
Is there any Canvas library that is like d3.js (is svg library). I have a website here and I coded a graph with svg elements however it is not efficient on smart phone's browsers and works so slow. I now, want to change it with a 2d canvas type of it and see whether it is better or not. Can you suggest a canvas library that is useful for this purpose?
Thanks...
D3 is not necessarily an svg only library - svg is used in many cases, but the library can do any kind of representations that you would like to make. See this example of parallel coordinates using canvas in D3, by Kai Chang: http://bl.ocks.org/2409451
Also see here for some discussion on performance issues, etc, that might be helpful: https://groups.google.com/d/topic/d3-js/mtlTsGCULVQ/discussion
I know I am late to the party, but times have changed, and I believe this question deserves an updated answer. SVG performance has improved a lot over the years and especially for the non-trivial graph-like visualizations it often gives superior performance; but it really depends on the exact use-case: If the visualization is simple and consists of thousands of elements, especially on mobile, Canvas may be the faster option. If the visualization is almost trivial, WebGL gives the best performance and beats Canvas hands-down - especially on mobile!
However WebGL especially and also Canvas are a bit harder to use than the declarative approach that SVG uses. Things like CSS animations and transitions are easy to do with SVG and give good performance due to being hardware accelerated and totally independent of JavaScript performance. Canvas and WebGL always require JavaScript.
If you take a look at the commercial graph drawing library yFiles for HTML you will see that it offers all three technologies at the same time. This is because all three can be the best choice, depending on the exact use-case.
There is a blog entry that compares the performance of SVG, Canvas, and WebGL especially in the context of graph visualization. It compares various graph sizes and categories of devices. The "conclusion" is that there is not a clear winner. Often times the combination of all three technologies gives the best results. For smaller graphs, though, SVG most of the time gives very good results and is a pleasure to work with. That's also the reason why d3.js has its focus on SVG, rather than Canvas and WebGL, I would say.
There is an interactive demo linked from that blog entry that let's you play with the various technologies and see their strengths and weaknesses. Of course the demo mainly compares the three technologies used in that specific library so your results may vary, but they spent a lot of time optimizing all three technologies in that library, so I think the results are not too biased.
Disclaimer: I work for the company that creates the above mentioned library, but I do not represent my employer here on SO. I think what I said should be valid not just for that library.
For the Samsung Olympic Genome Project facebook app, we used http://thejit.org to make the force directed graph style animation for the app. It's heavily modified by me and others on my team of course, and only plays a very small part in the app, but it's quite a powerful framework.
Chart.js is a javascript library that just came out that creates charts using HTML5 for rendering. Its not as feature inclusive as D3, but it is working to become exactly that in the future. http://www.chartjs.org/
Take a look at Cytoscape.JS which uses a HTML5 canvas for rendering. At the time of writing this it's in its infancy but the project seems promising. According to its wiki the library supports both desktop and mobile browsers:
Cytoscape.js is easily integrated into your webapp, especially since
Cytoscape.js supports both desktop browsers, like Chrome, and mobile
browsers, like on the iPad.
I realize that some people think it is crazy to re-implement all the UI functionality of HTML in a canvas-based framework (and there are some stackoverflow questions that suggest this), but is anyone actually working on a library like this?
To clarify, the library would render all UI elements like edit boxes, labels, buttons, combo boxes, list views, etc. on the canvas directly. There would be no HTML or CSS.
I stumbled upon this idea today. Found the library Zebra. Haven't tried it out yet.
https://zebkit.org/
For web apps I think this makes perfect sense. HTML/CSS is just not good enough to create stable apps easily. The DOM and layouts are just too quirky and the performance too low.
What we need is something like Silverlight but without the plugin. Stable components and a great framework.
Canvas apps could be made just as accessible as html web apps. Probably more so even.
Perhaps WebGL is even better, its performance is definitely better than Canvas if done properly.
Thunderhead was a mozilla experiment built along with bespin (now skywriter).
From the project description:
Thunderhead is a Mozilla Labs experiment to explore a JavaScript-based
GUI toolkit that works with DOM elements and canvas to render
components.
The problem is accessibility, canvas just isn't.
I've just reviewed zebkit.com today. Amazing and absolutely not crazy, rather essential. Try running most DOM node trees on a mobile device and you will soon know this is true. Then in contrast run the Zebkit kitchen sink demo and be shocked. You might have to reconsider your projects approach.
Coming from Java to HTML5 I definitely see some nice OOP at play in the Zebkit API, it is needed to provide the simple canvas some powerful structure. Also I really like the JSON support, it acts much like a CSS format for the canvas. Using JSON this way fits well into the Web Component mindset and the practicality of HTML partials. There are a lot of goodies in this API.
In the end all ways of producing graphics for the Web render pixels anyways. Maybe we have just added to many abstractions between the logic we what to produce and the end screen to realize this fact. With Zebkit it feels like your almost working at the native level, plus it adds in all the graces of Javascript and JSON, sweet indeed. Plus your free to mix and match in DOM as desired.
Now there is Flutter's CanvasKit renderer. Google docs is moving to Canvas.
Requirements:
List item
entirely client-side (except maybe conversion to image)
export to image
able to print chart
user interactivity (hover annotation)
multiple axis
price < $300 per site
IE6/7/8 compatibility optional
I've looked at the following:
List item
Highchart
rGraph
Zingchart
infoVis toolkit
jQuery Flot
Protovis
jqPlot
Which would you recommend based on your (or your team's) experiences?
Considering the following aspects:
List item
ease of use/learning curve
ease of extension/customizability
range of available charts/themes, aesthetics
level of support/buginess
Not to be a pain and sidestep you, but - and I say this as a Canvas lover - the best charting package I've used is gRaphael, which uses SVG/VML and not Canvas.
http://g.raphaeljs.com/
You tagged this as "canvas" and "html5" only but gRaphael fulfills most of your requirements. It is especially easy to use, and the learning curve is better, as SVG generally requires a lot less code to get a rich user experience than Canvas-based libraries do.
Here is the plugin for exporting-to-image for raphael-based apps
I'm not sure about the printing situation, but since it is SVG you ought to be able to print with less fuss than if you were using Canvas, but I don't think raphael has anything additional built in to deal with printing.
Of course, using SVG means that performance will suffer more if you plan on making a highly complex/large app with lots of animation and interactivity, but that is pretty unlikely in the world of charting, unless you're trying to win a "most nauseating way to present information" award or something.
I earnestly think you should start prototyping your app with gRaphael first. You should be able to get something up quicker than with a Canvas library which will let you evaluate fairly quickly whether it will be a good fit or not.
#Xerion - I'm on the ZingChart team. Zing should fit the bill pretty well, as it renders in HTML5 Canvas, SVG, VML, and/or Flash for compatibility and various scenarios. Simon had a great point about SVG -- more complex charts (data, features or otherwise) tend to cause SVG to fall behind Canvas in performance. See different scenarios here http://www.zingchart.com/#speedtest.
Feel free to contact me abegin[at]zingchart.com with any questions, or mention/follow us at twitter.com/zingchart.
Thanks.
I'm looking into providing several methods of visualizing a large volume of data. This may include, but will not be limited to, simple graphing. The techniques I'm exploring will involve shapes, text and lines. It will also involve interaction with elements (hiding, focusing, etc.) and animation (shifting, dragging, systematic reorganizing, etc.) of those elements.
SVG or Canvas seem like the obvious choices (in conjunction with a JS library--probably jQuery), but the lack of cross-browser availability is a concern. I'd prefer to avoid Flash/Flex, but right now it's the only rock solid, cross-browser technology I've found if support for IE7/8 is a requirement.
Does anyone have any other suggestions or any additional information that would make a technology I've listed seem even more appealing?
Thanks.
Check out the original Processing.org.
It may seem strange/anachronistic that they are using Java applets, but they were able to get better performance with Java than JavaScript. The applets seem to work everywhere, and you'll have access to lots of great Java libraries.
Don't think I saw this one mentioned: JavaScript InfoViz Toolkit
An interesting visualization I personally like is the treemap view. Nice for summarizing a lot of data in a single view.
You might want to take a look at Raphael and GRaphael. Raphael allows you to create vector graphics and will use SVG on SVG-capable browsers while automatically switching to VML on IE.
You could also take a look at the canvas-based processing.js.
HighCharts is a Javascript, good, free and cross-browser charting tool.
Take a look at the Highcharts demo
SVG is available on everything except IE, and VML is available on IE (since 5.5, IIRC). If you can serve both SVG and VML, you'll have vector graphics that virtually everyone can see. RaphaelJS is a Javascript library that can generate both formats from the same Javascript code, but of course that's just one way to do it.
Canvas is also available pretty much on everything except IE, but some crazy people wrote something called excanvas that emulates Canvas in, again, VML. From my friends and coworkers who have used it, I've heard the performance is worse than pretty much any other browser graphics solution, but if you want to do bitmap graphics portably, it's pretty much the only non-plugin game in town.
Which route you take -- vector or raster -- really depends on your application.
You might also try Protovis. (http://vis.stanford.edu/protovis/)
SVG and Canvas works for relatively simple data (i.e. where a few lines are enough). For complex data (say, frequency distributions, or something where you emit one sample per pixel), you should render a normal image on the server.
If you are using jquery for the graphing, I would definiately check out Flot which is as cross browser graphing/charting library.
Why do we need the html5 canvas element, when the same can be achieved through embedded svg?
SVG and canvas aren't really interchangeable technologies. SVG is a type of retained mode graphics where everything is drawn from a rather abstract model (the SVG document). Canvas on the other hand is a kind of immediate mode graphics, where there is no model and the client (JavaScript) must take care of redrawing, animations etc.
SVG is a markup language for vector graphics and has DOM. This makes it very easy to alter the content after its creation.
Canvas is a painting surface just like MS Paint without an undo button. You cannot alter the content. You only can overpaint it. It is very performant because the browser does not need to handle a complete DOM for the image. And there is a possibility that canvas can handle 3D drawing in the future.
http://people.mozilla.com/~vladimir/xtech2006/ has nice comparison.
With canvas you don't have to deal with the DOM, which leads to faster and easier to write code. SVG is a mess as a specification, too...
an illustration: My blog engine (blogger) doesn't support SVG (it's not a XHTML document). I wrote a tool converting SVG to the canvas element: http://plindenbaum.blogspot.com/2009/11/tool-converting-svg-to-canvas_22.html
Here is an explanation of how to parse a simple svg and draw it on a canvas..
http://www.ikeralbeniz.net/2010/11/03/jugando-con-html5-canvas-y-svg-i/
http://www.ikeralbeniz.net/2010/11/04/jugando-con-html5-canvas-y-svg-ii/
in further posts the svg parser will be completed with transparencies and gradients
you might also find this comparison useful:
http://dev.opera.com/articles/view/svg-or-canvas-choosing-between-the-two/
This isn't really a technical answer but I think it's the correct answer.
The bottom line is we don't need both. Yes I know there are differences between vector and raster graphics and different ways to control paths, objects, animations, etc. between the two, but to the end-user it's all the same. Yes, SVG is a little more powerful right now because of its longer existence but with a little more work you can do the same things with Canvas.
I believe the reality is Canvas is part of an overwhelming backlash against XML itself in web development. I believe most web developers, especially those working with limited time and resources, outside "enterprise" environments, dislike the complexity of XML. Canvas is part of a set of preferred just-do-one-thing technologies just like HTML5 is preferred over XHTML, JSON is preferred over XML, and even YAML is preferred over XML.
I think the idea is similar to the *nix philosophy of having many specific tools doing one thing right and efficiently rather than one mega tool doing many things. (It's also similar to the philosophy held by many fixed gear bicycle riders who shun incredibly precise and advanced derailleur technology for the simplicity of one direct drive gear.)
Don't get me wrong, I believe XML is an incredibly powerful and brilliant technology thought up and developed by brilliant people to be the ultimate Swiss army-knife of the web, programming, configuration, data storage, etc; but that doesn't mean it's easier to manage and style a series of complex paths than it is to just draw pixels on a .
I know my answer is opinionated and I don't intend this to be a flame. I love SVG and I wish it would have gotten more support over the years (especially from IE), but I feel the tide turning towards Canvas simply due to the psychology of standards setters and the web developers that influence them.
Long term I'd like to see SVG make XML optional and move to a more JSON-like structure that's simpler to manipulate with JavaScript, perhaps even becoming a vector-based Canvas context. That would be the best solution for the web in my opinion.
Because we then do not need to worry about what support such embedding ;-)
In this fashion the focus for application developpers is to adhere to standards and let the client designers do the same. and hence spare everyone to worry about plug-ins, versions, security setups, etc...