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.
Related
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 :)
So I have an animation that I'm coding in javascript and HTML5 (no libraries, no plugins, no nothing and I'd like it to stay that way). The animation uses physics (basically a bunch of unusual springs attached to masses) to simulate a simple liquid. The output from this part of the program is a grid (2d-array) of objects, each with a z value. This works quite nicely. My problem arises when drawing the data to an HTML5 Canvas.
That's what it looks like. Trust me, it's better when animated.
For each data point, the program draws one circle with a color determined by the z value. Just drawing these points, however, the grid pattern is painfully obvious and it is difficult to see the fluid that it represents. To solve this, I made the circles larger and more transparent so that they overlapped each other and the colors blended, creating a simple convolution blur. The result was both fast and beautiful, but for one small flaw:
As the circles are drawn in order, their color values don't stack equally, and so later-drawn circles obscure the earlier-drawn ones. Mathematically, the renderer is taking repeated weighted averages of the color-values of the circles. This works fine for two circles, giving each a value of 0.5*alpha_n, but for three circles, the renderer takes the average of the newest circle with the average of the other two, giving the newest circle a value of 0.5*alpha_n, but the earlier circles each a value of 0.25*alpha_n. As more circles overlap, the process continues, creating a bias toward newer circles and against older ones. What I want, instead, is for each of three or more circles to get a value of 0.33*alpha_n, so that earlier circles are not obscured.
Here's an image of alpha-blending in action. Notice that the later blue circle obscures earlier drawn red and green ones:
Here's what the problem looks like in action. Notice the different appearance of the left side of the lump.
To solve this problem, I've tried various methods:
Using different canvas "blend-modes". "Multiply" (as seen in the above image) did the trick, but created unfortunate color distortions.
Lumping together drawing calls. Instead of making each circle a separate canvas path, I tried lumping them all together into one. Unfortunately, this is incompatible with having separate fill colors and, what's more, the path did not blend with itself at all, creating a matte, monotone silhouette.
Interlacing drawing-order. Instead of drawing the circles in 0 to n order, I tried drawing first the evens and then the odds. This only partially solved the problem, and created an unsightly layering pattern in which the odds appeared to float above the evens.
Building my own blend mode using putImageData. I tried creating a manual pixel-shader to suit my needs using javascript, but, as expected, it was far too slow.
At this point, I'm a bit stuck. I'm looking for creative ways of solving or circumnavigating this problem, and I welcome your ideas. I'm not very interested in being told that it's impossible, because I can figure that out for myself. How would you elegantly draw a fluid from such data-points?
If you can decompose your circles into two groups (evens and odds), such that there is no overlap among circles within a group, the following sequence should give the desired effect:
Clear the background
Draw the evens with an alpha of 1.0 (opaque)
Draw the odds with an alpha of 1.0 (opaque)
Draw the evens with an alpha of 0.5
Places which are covered by neither evens nor odds will show the background. Those which are covered only by evens will show the evens at 100% opacity. Those covered by odds will show the odds with 100% opacity. Those covered by both will show a 50% blend.
There are other approaches one can use to try to blend three or more sets of objects, but doing it "precisely" is complicated. An alternative approach if one has three or more images that should be blended uniformly according to their alpha channel is to repeatedly draw all of the images while the global alpha decays from 1 to 0 (note that the aforementioned procedure actually does that, but it's numerically precise when there are only two images). Numerical rounding issues limit the precision of this technique, but even doing two or three passes may substantially reduce the severity of ordering-caused visual artifacts while using fewer steps than would be required for precise blending.
Incidentally, if the pattern of blending is fixed, it may be possible to speed up rendering enormously by drawing the evens and odds on separate canvases not as circles, but as opaque rectangles, and subtracting from the alpha channel of one of the canvases the contents of a a fixed "cookie-cutter" canvas or fill pattern. If one properly computes the contents of cookie-cutter canvases, this approach may be used for more than two sets of canvases. Determining the contents of the cookie-cutter canvases may be somewhat slow, but it only needs to be done once.
Well, thanks for all the help, guys. :) But, I understand, it was a weird question and hard to answer.
I'm putting this here in part so that it will provide a resource to future viewers. I'm still quite interested in other possible solutions, so I hope others will post answers if they have any ideas.
Anyway, I figured out a solution on my own: Before drawing the circles, I did a comb sort on them to put them in order by z-value, then drew them in reverse. The result was that the highest-valued objects (which should be closer to the viewer) were drawn last, and so were not obscured by other circles. The result is that the obscuring effect is still there, but it now happens in a way that makes sense with the geometry. Here is what the simulation looks like with this correction, notice that it is now symmetrical:
I'm trying to draw a tiled background using Javascript on an HTML5 canvas, but it's not working because shapes that intersect the edges of the canvas don't wrap around to the other side. (Just to be clear: these are static shapes--no motion in time is involved.) How can I get objects interrupted by one side of the canvas to wrap around to the other side?
Basically I'm looking for the "wraparound" effect that many video games use--most famously Asteroids; I just want that effect for a static purpose here. This page seems to be an example that shows it is possible. Note how an asteroid, say, on the right edge of the screen (whether moving or not) continues over to the left edge. Or for that matter, an object in the corner is split between all four corners. Again, no motion is necessarily involved.
Anyone have any clues how I might be able to draw, say, a square or a line that wraps around the edges? Is there perhaps some sort of option for canvas or Javascript? My google searches using obvious keywords have come up empty.
Edit
To give a little more context, I'm basing my work off the example here: Canvas as Background Image. (Also linked from here: Use <canvas> as a CSS background.) Repeating the image is no problem. The problem is getting the truncated parts of shapes to wrap around to the other side.
I'm not sure how you have the tiles set-up, however, if they are all part of a single 'wrapper' slide which has it's own x,x at say 0,0, then you could actually just draw it twice, or generate a new slide as needed. Hopefully this code will better illustrate the concept.
// Here, the 'tilegroup' is the same size of the canvas
function renderbg() {
tiles.draw(tiles.posx, tiles.posy);
if(tiles.posx < 0)
tiles.draw(canvas.width + tiles.posx, tiles.posy);
if(tiles.posx > 0)
tiles.draw(-canvas.width + tiles.posx, tiles.posy);
}
So basically, the idea here is to draw the groupings of tiles twice. Once in it's actual position, and again to fill in the gap. You still need to calculate when the entire group leaves the canvas completely, and then reset it, but hopefully this leads you in the correct direction!
You could always create your tillable image in canvas, generate a toDataUrl(), and then assign that data url as a background to something and let CSS do the tiling.. just a thought.
Edit: If you're having trouble drawing a tillable image, you could create a 3*widthx3*width canvas, draw on it as regular (assuming you grab data from the center square of data as the final result), and then see if you can't draw from subsets of the canvas to itself. Looks like you'd have to use:
var myImageData = context.getImageData(left, top, width, height);
context.putImageData(myImageData, dx, dy);
(with appropriate measurements)
https://developer.mozilla.org/En/HTML/Canvas/Pixel_manipulation_with_canvas/
Edit II: The idea was that you'd have a canvas big enough that has a center area of interest, and buffer areas around it big enough to account for any of the shapes you may draw, like so:
XXX
XCX
XXX
You could draw the shapes once to this big canvas and then just blindly draw each of the areas X around that center area to the center area (and then clear those areas out for the next drawing). So, if K is the number of shapes instead of 4*K draws, you have K + 8 draws (and then 8 clears). Obviously the practical applicability of this depends on the number of shapes and overlapping concerns, although I bet it could be tweaked. Depending upon the complexity of your shapes it may make sense to draw a shape 4 times as you originally thought, or to draw to some buffer or buffer area and then draw it's pixel data 4 times or something. I'll admit, this is some idea that just popped into my head so I might be missing something.
Edit III: And really, you could be smart about it. If you know how a set of objects are going to overlap, you should only have to draw from the buffer once. Say you got a bunch of shapes in a row that only draw to the north overlapping region. All you should need to do is draw those shapes, and then draw the north overlapping region to the south side. The hairy regions would be the corners, but I don't think they really get hairy unless the shapes are large.... sigh.. at this point I probably need to quiet down and see if there's any existing implementations of what I speak out there because I'm not sure my writing off-the-cuff is helping anybody.
I've looked around for layering objects within the same canvas but haven't found a lot of information about it.
At the moment I've used the multiple canvas technique to layer things on top of each other
example:
canvas Holder <--- this holds all other canvas's
loading canvas
menu canvas
game canvas
background canvas
and by adding them to the "stage = new stage (mainCanvas)" in a specific order, i get the desired layering
stage.addChild(background);
stage.addChild(game);
stage.addChild(menu);
stage.addChild(loading);
This works great, however I'm wondering whether there is a way to change the zIndex of an image added to the 'game' canvas if I had 2 images in that canvas?
I've seen this sort of thing done in the fieldrunners game, the game follows a grid like format and when you place a shooter in the square above another shooter, is gets repositioned behind it..
http://fieldrunnershtml5.appspot.com/#sd --- works in chrome
any ideas how it was done?
Thanks
There is no need for multiple canvases. When you work with a game in canvas 2d you usually clear and redraw the canvas ~60 times per second. What you draw last ends up on top. So in order to simulate layers you sort all game objects in an array based on their z-index then you iterate over all objects in the array, invoking their draw methods.
There is much room for optimizing such a renderer, but this is a basic and simple way to make it work.
A canvas is just pixels - it has no "layers".
If you want to perform parallax scrolling, that sort of thing, put multiple canvases in the same place, and use transparency to show the ones behind.
Your technique using multiple canvases to implement layers is totally good approach. You should also keep track on which layer needs to be cleared/redrawn - for example map should be refreshed only when scrolled or GUI/HUD really doesn't need to be redrawn 60 times per second.
There is no such thing as z-index or objects in canvas, all mechanisms depends on your own implementation. For example you can make an array of commands or objects to draw - then sort it by zIndex (or whatever you name it) and execute each element.
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