Performance?

[JosefJezek]

http://jsperf.com/paper-vs-processing-vs-raphael/4

[noisik]

Also interested in this topic. Im new to paperjs, so i start testing the "Working with Mouse Vectors" paperscript on my iPhone and the first thing i noticed is how slow the performance is (delay on drag). There is a way for improve performance on mobile devices?

[puckey]

I do not see why you would remove and add the path each frame. The bonus of using Paper.js is that it has a DOM. @noisik there are indeed improvements to be made on the mobile side, do you have any advice for us?

[lehni]

I've been looking through this quite a bit. The comparison is interesting but not fair at all, for various reasons:

• There is a huge difference between telling the canvas to simply draw a rectangle, and asking Paper.js to construct a rectangular shape as a Path that you then can access the segments on, and change further. This is what the Path constructors are there for, after all.
• We are considering adding Shape.* constructors (e.g. Shape.Rectangle, Shape.Circle) which would then create elements that do not hold path descriptions, but are just defined a location and a size. These would then use these simple, faster drawing commands, and performance should become way better as a result. There could even be the option to expand such Shapes into Paths.
• Even when using such an approach, a DOM based structure will never be able to compare with a state machine in terms of performance, but offers many advantages otherwise when dealing with the anatomy of paths and documents, which is the big advantage of Paper.js, and the area that we are focusing on with this library.

[lehni]

I have looked into this a bit further:

First I started by creating a preliminary Shape class, to see if that yields improvements. Weirdly enough, it was almost as slow. This means our actual Path / Segment code must perform well:

https://github.com/paperjs/paper.js/blob/master/src/item/Shape.js

Then I did some profiling, and found out that almost 1/4 of the time was spent in Style related code. So I reworked the Style related code to improve its performance, with notable results:

http://jsperf.com/paper-vs-processing-vs-raphael/8

On Safari, this test now runs notably faster than Raphael, but still slower than libraries that do not maintain a DOM. This is to be expected and no surprise at all, for all the reasons stated above.

I will close this issue now.

[puckey]

A more fitting way would be to create the rectangle in the initialization code and only call view.draw() every iteration. The rectangle does not need to be recreated each time: http://jsperf.com/paper-vs-processing-vs-raphael/12