Paper.js — The Swiss Army Knife of Vector Graphics Scripting

[haberman]

Why implement vector graphics on Canvas when you could use SVG?

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."

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++).

[epistasis]

There's no reason that a Canvas implementation would be doing rasterization in JavaScript; the Canvas API is like Postscript or the Cairo API, and javascript will only be calling high-level functions such as specifying gradient or Bezier curve parameters.

[csytan]

I don't think SVG is particularly suited to animation, as it would require manipulating multiple DOM elements. This tends to be quite slow compared to redrawing the canvas.

[perfunctory]

This is what amuses me about software. SVG which is specifically designed for vector graphics is slower than "not native" solution.

[gruseom]

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.

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.

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.

[notJim]

That approach you describe to building an SVG tree is a common performance optimization when manipulating the DOM for HTML as well. I'd be curious to hear if you've tried a) using a DocumentFragment, b) detaching the node using removeNode, manipulating, then adding it back, and c) simply working with a node (createNode) and then adding it in after manipulations are done. The basic idea is that working with the live DOM is slow, while working with detached nodes is fast. Note that I haven't really tried this stuff out that much. Maybe I'll work up a little benchmark over the weekend or something.

I'm pretty sure Paul Irish's talk [1, 2] is where I read about this.

[1]: http://www.slideshare.net/paul.irish/perfcompression

[2]: http://vimeo.com/10295601

[maresca]

Has anyone used both this and raphaeljs? How do the two compare on features, browser compatibility, performance, etc?

[JeanPierre]

I haven't used Paper.js, but I've used Raphaël and the main differences I see right now is that Paper uses Canvas, while Raphaël simulates/uses SVG. As a result, Paper should be more practical for making dynamic content that uses user input or is "very dynamic".

Raphaël on the other hand, provides a simple system for making relatively "static" vector images with very good support for a lot of browsers (IE6 support, even). If you need user input, I think I would've tested out Paper and most likely ended up with that.

So basically: Raphaël for vector images that may be scaled and simple, dynamic images. Paper for animations and e.g. games.

[skrebbel]

Paper.js admits to not supporting IE < 8 (bottom of http://paperjs.org/about/). Other browser support is not even listed. I guess this means that it's not usable for most serious end-user apps now.

[aarondf]

The Mona Raster, made with Paper.js

http://d.pr/Oa4n

[EDIT] Slightly sharper eyes.

[fedorabbit]

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.

[patrickaljord]

It uses no more than 15% CPU on default smoothing and 19% CPU here on bouncing ball with chrome 14 on ubuntu with a i5 CPU 670 @ 3.47GHz regular PC.

[fomojola]

Internet Explorer compatibility, anyone? I mean, I'm as much in favor of the latest and greatest as the next man, but...

RaphaelJS has IE covered.

[repos]

Yeah but you are really comparing two different things here (regardless of IE support). If we just compare svg (raphael) and canvas (paper), we see SVG is not as recommended for animation whereas canvas is.

[bmj]

Does anyone know if this would work on top of excanvas (http://excanvas.sourceforge.net/)?

[laughinghan]

The obvious comparison is with Raphael.js (raphaeljs.com)

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?

[kleiba]

That website makes my CPU sweat.

[joshuacc]

I'm curious: What browser are you using? Chrome 13 on my desktop is really quick.

[Vivtek]

Everything on Canvas seems to.

[emiranda]

Anyone happen to know where I can find general information on implementing something like this? http://paperjs.org/examples/chain/ 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.

[fserb]

I think you got something wrong there. The source code for chain (accessible by pressing the "source" button on the top right corner of the page) is just 35 lines long and only does the chain/snake effect.

[Shana]

Q-anyone have comparisons to the processing.js (processing) wrap?

[mhd]

I still miss Display Postscript.

[florin_]

any 3d on canvas?

[hugs]

don't know about 3d/canvas in paper.js, but you should check out three.js, which does do 3d on canvas: https://github.com/mrdoob/three.js/

[noduerme]

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:

var a = new Sprite(); var b = new Sprite(); a.addChild(b); b.x = 100; a.rotation = 45;

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.

[bradshaw1965]

EaselJS allows a parent-child display list relationship and mouse interactions with sprites. http://easeljs.com/