
Paper.js — The Swiss Army Knife of Vector Graphics Scripting - hakim
http://paperjs.org
======
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++).

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

~~~
haberman
The alternative is keeping your own "DOM" of vector objects in a JavaScript-
based scene graph. Why would this be more efficient than manipulating the DOM?

~~~
donpark
Because DOM elements are _much_ heavier than Javascript objects in size,
query/update performance, and update requirements.

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

~~~
gruseom
Yes, using innerHTML to bypass the HTML DOM is the poster child for this kind
of thing.

We've tried all the alternative techniques you mention (with HTML DOMs, that
is - I don't think any of them work with SVG) and had disappointing results.

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

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

~~~
k33l0r
I'd say that not supporting browsers below IE8 (or even IE8 itself) is
reasonable for many projects. I just looked at the stats for a few of our
sites and total IE browser share is around 4–7% on them.

If you have a similar situation on your site/application, I think it's
perfectly reasonable not to support anything other than modern browsers, but
you have to look at your own stats.

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

~~~
laughinghan
Raphael has put a _lot_ of effort into a very robust DOM-based animation
implementation, and at least in their examples and my experience their
animation has worked beautifully.

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

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

~~~
emiranda
Yes, it's 35 lines. But that's not including the source. Such as the
definitions for Point(), which is a couple 100 lines of code, not including
its dependencies. I want to port it over to Flash, which is in ActionScript
not JavaScript.

------
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/>

~~~
noduerme
hm. EaselJS has evolved since I last saw it. The parent-child relationships
look good. +1. -1 is Grant got the same idea I had about two years ago after
seeing my code, and has gone through 3.2 major revisions to still arrive at a
relatively inferior product with 10x as much code. (yeah, I wrote
strikedisplay =) Not only that, he's the loon who's responsible for Flash 5
being a completely unusable product because of his insanely horrible side
panel components and his greed in pushing them through with Adobe. Oh yeah, I
also insulted him about the project panel which led him to rip off my work
from StrikeDisplay.

All that aside, it does appear that in the newest version Grant has finally
caught up to almost where my code was about a year ago, and since I haven't
maintained the project for almost two years, that's saying a lot =) Great work
Grant! If I had a serious HTML5 project, I'd just loooove to use your code for
it =\ hah. Although I'm sure if one of those arises I could write something
better in a few hours.

The trouble is, right now there is still nothing to be gained from writing
something on a Canvas. It's too slow to play on an iphone, and there's no
point in using it on a desktop when you can use Flash. And now anybody can
release a game in html5 w/o any coding whatsoever, guaranteed. Grant: We are
both pissing on the same lamppost in hopes of adding a tiny pile of sodium to
it. Who gives a fck. Seriously, God Bless, just "rule the universe in HTML5".
I only wrote my code a couple years ago to prove it was slower than the same
thing in Flash. You want to make a life's work out of it? 3.2 major revs? Go
ahead man.

