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

http://paperjs.org

by hakim • 15 years ago

267 41 15 years ago

paperjs.org

kleiba• 15 years ago

That website makes my CPU sweat.

Vivtek• 15 years ago

Everything on Canvas seems to.

joshuacc• 15 years ago

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

maresca• 15 years ago

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

JeanPierre• 15 years ago

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• 15 years ago

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• 15 years ago

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.

fomojola• 15 years ago

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• 15 years ago

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.

laughinghan2• 15 years ago

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.

bmj• 15 years ago

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

fedorabbit• 15 years ago

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• 15 years ago

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.

haberman4• 15 years ago

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• 15 years ago

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.

haberman4• 15 years ago

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?

MatthewPhillips• 15 years ago

SVG is hardware accelerated in IE9 and coming to Chrome as well. When that happens I doubt there will be much of a difference performance wise. Canvas and SVG will serve different ends. Doing something like GUI in Canvas would be an incredible pain, whereas doing it in SVG (using raphael.js) is a breeze. Canvas is better for games.

euroclydon• 15 years ago

Don't forget SMIL.

epistasis3• 15 years ago

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.

perfunctory• 15 years ago

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

epistasis3• 15 years ago

The problem with SVG was that it wasn't really designed as much as it was dreamed. And it was also dreamed up in the middle of the whole "all data must be shoe-horned into XML" collective nightmare, which makes it less than ideal as a scene graph.

It was also abandoned as soon as Adobe acquired Macromedia, and thus Flash, meaning that there was no longer any reason for Adobe to push for a Flash alternative. There have never really been any good implementations, and it seems as though the spec wasn't written by anybody who'd have to eventually write an implementation.

florin_• 15 years ago

any 3d on canvas?

hugs• 15 years ago

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/

Shana• 15 years ago

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

emiranda2• 15 years ago

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• 15 years ago

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.

emiranda2• 15 years ago

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.

noduerme2• 15 years ago

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• 15 years ago

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

noduerme2• 15 years ago

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.

aarondf• 15 years ago

The Mona Raster, made with Paper.js

http://d.pr/Oa4n

[EDIT] Slightly sharper eyes.

gruseom2• 15 years ago

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• 15 years ago

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

gruseom2• 15 years ago

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.

mhd• 15 years ago

I still miss Display Postscript.

laughinghan2• 15 years ago

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?

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

Related Stories