Why implement vector graphics on Canvas when you could use SVG?<p>EDIT: Seems to be answered in the FAQ: "We have decided to use the Canvas object as the main backend for now because it is faster than SVG and allows us to implement and optimize our own Scene Graph / Document Object Model. We will be offering SVG (and hopefully PDF) importing and exporting in the future."<p>But it seems hard to believe that doing vector->bitmap rasterization in JavaScript is going to be faster than using the browser's SVG implementation (written in C++).
Regarding vector graphics performance, there's a weird way to use SVG that is sometimes much faster than Canvas: use string concatenation to build up a huge blob of SVG markup and then splat it into the browser all at once by setting innerHTML on an SVG element. We rely on this trick for UI performance in our web app. In fact, we do it on every scroll and/or mousemove. The amount of computation you can get away with in JS without noticeably slowing down the renderer is nothing short of astonishing.<p>Given how clunky SVG can be, it's surprising that this technique works so well. I believe the performance gain comes from batching everything you want to render into a single ginormous round trip between JS and native code. With Canvas, you don't have that option, so you have to cross the grand canyon with every call. The equivalent in SVG would be making a series of tweaks to the SVG DOM, and that's even slower. Much better to rebuild the entire DOM yourself in text and overwrite the old one.<p>As a bonus, you can take the same approach in IE using VML. Though the markup is different, the SVG and VML models are close to isomorphic - not close enough to abstract over without an annoying impedance mismatch, but much closer than either is to Canvas. Thus this technique affords a good way to get graphics performance out of both the modern browsers (SVG) and the pre-9 IEs (VML) for as long as the latter are around.
default smoothing example uses 52% - 62% CPU at run time on my macbook pro i7 duo core 2.66GHz laptop. Bouncing ball uses 100% on average. Pretty cool script! it makes a good example what today's browser is capable of.
The obvious comparison is with Raphael.js (raphaeljs.com)<p>Wouldn't it be great if someone did all the RaphaelJS examples in PaperJS, and vice versa, so we could compare performance and ease of use?
Anyone happen to know where I can find general information on implementing something like this? <a href="http://paperjs.org/examples/chain/" rel="nofollow">http://paperjs.org/examples/chain/</a> I'm interested in implementing this mechanic in Flash (for a game). I looked through the source code and it seems like a lot of code just to get to the point. Hoping to find something more basic that I can port over.
proce55ing is great for what it is / does, but there's a large gap between that and building functional games and animations, which isn't addressed by their screen graph model (nor this one). At issue, and missing, are parent-child relationships in which transformations and mouse events can be factored or transmitted up or down a display chain in the screen graph. To my knowledge, the only existing library that does this on Canvas is StrikeDisplay (strikedisplay.blogspot.com). In general, the ability to do that doesn't impinge on the ability to use native canvas vector functions in any way; but it simplifies the mixture of vector and raster images for animation, and acts as a better tool to let coders focus on the game they're trying to build rather than the intricacies of the canvas processing -- or to step it up, the raster and/or vector transformations -- behind something like:<p>var a = new Sprite();
var b = new Sprite();
a.addChild(b);
b.x = 100;
a.rotation = 45;<p>Which ideally should rotate both a and b by 45 degrees clockwise, with b offset in the rotation around a's axis by 100 px.