I made a speedtest to compare Snap.svg (SVG) to FabricJS (CANVAS):
http://jsbin.com/tadec/7 function dummy().
In Chrome SVG renders in 120 ms, while CANVAS renders in 1100 ms. SVG is 9x faster than CANVAS.
Fabricjs.com page says in this example that Raphael takes 225 ms and Fabric takes 97 ms (parsing: 80, rendering: 17).
I have had an impression (after reading fabricjs.com and paperjs.org) that FabricJS and more generally Canvas is faster than SVG.
My speed test claims that SVG is significantly faster than Canvas (at least Snap.svg seems to be significantly faster than FabricJS).
Why FabricJS is so slow in my test? Have I made some mistake in comparison, because I'm surprised that SVG seems to be faster than Canvas in my speed test.
EDIT: My question is two-parted: Why rendering speed is so much slower in FabricJS and why dragging speed as well?
Your benchmark is broken in my opinion, because beside measuring drawing to canvas you are measuring parsing of a huge string containing a path, over and over again. Separate this code out of the loop and you should get more reliable results.
Measurements that are provided for canvas libraries are provided for drawing, not for parsing or other pre-processing work. If you use canvas like you use SVG, then yes, it will be slower. It is not intended to be used like SVG. FabricJS provides a way to do that, but it is not optimal. One solution would be to parse path once, and then use same path over and over instead of parsing it every time.
Also, measurements are given probably for drawing a canvas, not for interaction with parts. As you say in comments, rendering may be improved, but why does dragging a shape take so much longer? Because:
maybe path is being reparsed on each redraw (not sure how FabricJS works)
because SVG can redraw only certain parts of image that you are moving, and canvas is usually redrawn completely. Why? Because you can't "erase" part of canvas where a shape used to be. So entire canvas is erased, and new positions are redrawn.
Why do then people say canvas is faster than SVG for such scenarios? Because it is if you use it properly. It will be more work, but it will work much faster.
Don't use SVG paths for drawing shapes, or use simple paths and cache them
Cache shapes which you use often into off-screen (hidden canvas) and then copy from that canvas onto visible canvas when needed
If you have multiple independant layers of an image (for example 3 layers in a game, if you have background sky which is moving, background mountains which are moving slower and a character), use multiple canvases. Put canvases one over another, draw sky on the bottom canvas, draw mountains on second canvas and draw character on top canvas. That way, when character on top canvas moves, you don't have to redraw entire background.
I hope my answer is useful for you :)
Related
i'm a beginner in Javascript so please bear with me.
Basically I'm making a sandbox drawing facility for a website using Javascript. And this is done using the canvas. What I need to do is to be able to resize the canvas dynamically but at the same time keep everything on the canvas to scale.
I don't think this question has been asked before. It seems trivial but I currently have all my objects on the canvas defined in absolute coordinates. I also have mouse events to use to draw things. And when I want to enlarge the canvas (by doubling the size say). All the objects inside won't be enlarged properly to scale and the mouse coordinate system would be messed up too.
Only solution i can think of is add a scale factor to ALL my drawing parts, but this is very tricky with a lot of code. Is there a better way?
If you don't mind jaggies on your double-sized canvas drawings then you can simply use CSS to double-size your canvas. Then divide every incoming mouseEvent coordinate by 2.
If you don't want jaggies on your double-sized canvas then:
Double-size the canvas element: canvas.width*=2 and canvas.height*=2 This automatically erases all canvas content.
Scale up the canvas: context.scale(2,2)
Redraw all your drawing parts using the unchanged original coordinates. A happy note: you do not have to scale any of your drawing coordinates -- context.scale automatically does that for you.
Divide every incoming mouseEvent coordinate by 2.
The answer to this stackoverflow question effectively says to retrace the steps taken to draw a rectangle:
fillRect
by doing:
clearRect
First of all when I read this answer, I thought to just draw a white box the entire width and height of the canvas.
After thinking a bit more about how the Canvas element can save, and restore and the fact it implements a clearRect, does this mean that simply drawing another large rectangle could eat resources, if doing something like redrawing an entire bar graph every 100ms.
Originally drawing a bar graph every 100ms drew bars on top of each other, thus not being able to see the new bars because they're being layered.
But now, drawing a white rectangle as well, means that many rectangles are getting drawn, layered and it seems that the Canvas element tracks these?
Does this mean that it is possible to effectively overload the element, or overload the browser?
the canvas does not track the drawing operations, but it tracks states. And the color values of individual pixels. If you draw a red rectangle you actually set the state to "draw red" and then set a rectangular shaped area of pixels to the currently drawn color (there are also different other drawing operations than just draw red on-top but I don't have experience with the so I can't tell you much other than that they exist)
For performance reasons you want to (among many other things) minimize
the amount of pixels you change
the amount of states you change
the difference between clearRect and width = width is that clearRect clears out the pixel data in the given area, while width = width clears out all pixel data and all states, like transformations, and styles. I think you already see the difference, there are a lot more things to consider (like Garbage Collection blocking your drawloop being one) but that would get a bit offtopic.
I'm not sure what you mean with overloading the browser. If you mean blocking and making the UI unresponsive then yes it's a thing that can and will happen since javascript is single-threaded and there are many ways you can accomplish it, but most likely not with such a reasonable operation :)
The worst thing you can do with drawing is make it super choppy on slow CPUs. Using requestAnimationFrame() instead of setTimeout()(which I assume you currently use because you mentioned 100ms) for your drawloop(s) is almost always a good and safe way to make sure your drawing will not block the UI.
the Canvas element tracks these [rectangles]
It doesn't track painting operations, as far as I know. (It's up to the implementation, but I don't know of any implementation that does.) You might be thinking of how it can save and restore things like transforms and paint colors.
so i have been trying to work on a canvas sketching app. and i had this problem where the line drawn are very unclean. As you can see from image below.
then i tried this and got the below result which is what i desire.
But this created a new problem, the eraser function wont work. Now I've been trying to make this two work for sometime, but just could'nt do it.
So what i want is a new smoothing technique or a way to make the above two work.
BTW here is the demo without smoothing: http://jsbin.com/axarun/1/edit
and here is the demo with smoothing: http://jsbin.com/aviluk/2/edit
Thnx in advance.
Method 1:
You can "force" the canvas to use anti-aliasing by doing this:
ctx.translate(0.5, 0.5);
Force in quotes as this is dependent on actual implementation in the browser you're using. Currently there is no way to enable/disable anti-alias by intention.
Method 2:
Set the canvas to "high-resolution" by setting the canvas itself to double size, but force it to be displayed in the original size by styling the canvas element with CSS rules:
<canvas id="myCanvas" width="1600" height="1200"
style="width:800px;height:600px" />
Just remember to double your mouse-coordinates as well as pen-width. This will eat 4x more memory and performance, but will give you high-resolution lines (in appearance).
In this case the browser will treat the canvas as an image and apply anti-aliasing as it does for any scaled image, and not the canvas' method for anti-alias.
Please note that this is not the same as applying scale transform to the canvas.
See demo of "hi-res canvas" here:
http://jsfiddle.net/q2t5A/
Method 3-ish:
For actual smooth lines you can check out my function to do so here:
http://www.codeproject.com/Tips/562175/Draw-Smooth-Lines-on-HTML5-Canvas
This takes an array of x/y couples and smooths the line (cardinal spline). The lines will go through the original points and no control points are needed.
This will of course imply that you record the actual points, and when mouse up you redraw the canvas using the curve() function in this code. That would be a correct approach in any case, to record the strokes in an array and then redraw (this will also allow you to use layers). There are workarounds to avoid render everything by using off-screen
canvases to store f.ex. each layer. By drawing a canvas onto another with a small non-integer offset will force anti-alias (but see point 1).
I have a canvas animation that sometimes redraws the exact same element over another (it is a long story why this is necessary) but it happens, and it happens often enough.
Now I assumed that drawing an element (using a context path and the stroke method) over an existing exact replica of the image should do nothing at all to my animation. Instead it draws over the past image and blurs all the sides (as if it didn't exactly draw at the same location.
Please let me know if there is a way to fix this
Thanks
This is happening because canvas strokes are anti-aliased. In a practical sense you're drawing some semi-opaque pixels over some other semi-opaque pixels, and where the pixels are overlaid their opacities are added together. I don't think you can (currently) force the canvas object to turn off anti-aliasing on strokes, so you may just have to live with it. Is it that big of a problem?
http://img813.imageshack.us/img813/303/canvasl.png
EDIT: I guess you could try using PNGs with transparent backgrounds for your markers, instead of drawing them with strokes. https://developer.mozilla.org/en/Canvas_tutorial/Using_images
I'm currently implementing a HTML canvas based webapp that features panning. Is there a way to use an auxiliary buffer to hold the presently visible area so when I pan I don't have to redraw the whole canvas and only have to draw the newly visible areas?
See my previous response to a related question: What is the fastest way to move a rectangular (pixel) region inside a HTML5 canvas element
Just draw the entire canvas in a div that has overflow:hidden and implement panning as re-positioning the top and left of the canvas within that div. It is much faster. And don't worry about drawing canvases tens of thousands of pixels wide/tall, I've successfully used this on very-very large and complex HTML and SVG elements.
Take a look at the pixel manipulation API.
http://dev.w3.org/html5/2dcontext/#pixel-manipulation