I am trying to draw a rough outline of a building in canvas.
I'm achieving the effect below by creating a series of squares for each side, plus the top 'roof' and then drawing them in sequence basically following the Painter's algorithm.
The screenshot on the left is showing how it should look. This is painting each square separately.
To improve performance I want as few .stroke() and .fill() calls as possible so I queue up all the moveTo() and lineTo() calls and paint them all in one big go.
Tests have shown that (at least for lines) this gives a massive performance improvement and I've verified it myself.
Unfortunately as you can see from the right screenshot, when I paint the buildings only once at the end the layering basically gets destroyed. It paints things in a seemingly random order.
Is the canvas supposed to work this way? Why doesn't it draw everything in the order I told it to draw in like the first screenshot?
Does anyone know a good work around for this behaviour?
If you're sending it all the moveTos and lineTos etc as one big batch, it's going to draw them as if you were rendering one large shape (where you'd want to see all the inner strokes).
There's a minor performance penalty for running multiple draw operations, but it's usually not worth making your code harder to understand and debug.
Related
I understand it's often faster to pre-render graphics to an off-screen canvas. Is this the case for a shape as simple as a circle? Would it make a significant difference for rendering 100 circles at a game-like framerate? 50 circles? 25?
To break this into two slightly different problems, there are two aspects to what you're asking:
1) is drawing a shape off-screen and putting it on-screen faster
2) is drawing a shape one time and copying it to 100 different places faster than drawing a shape 100 times
The answer to the first one is "it depends".
That's a technique known as "buffering" and it's not really about speed.
The goal of buffering an image is to remove jerkiness from it.
If you drew everything on-screen, then as you loop through all of your objects and draw them, they're updating in real-time.
In the NES-days, that was normal, because there wasn't much room in memory, or much power to do anything about it, and because programmers didn't know much better, with the limited instructions they had to work with.
But that's not really the way games do things, these days.
Typically, they call all of the draw updates for one frame, then they take that whole frame as a finished image, and paste that whole thing on the screen.
The GPU (and GL/DirectX) takes care of this, by default, in a process called "double-buffering".
It's a double-buffer, because there's room for the "in-progress" buffer used for the updates, as well as the buffer that holds the final image from the last frame, that's being read by the monitor.
At the end of the frame processing, the buffers will "swap". The newly full frame will be sent to the monitor and the old frame will be overwritten with the new image data from the other draw calls.
Now, in HTML5, there isn't really access to the frame-buffer, so we do it ourselves; make every draw call to an offscreen canvas. When all of the updates are finished (the image is stable), then copy and paste that whole image to the onscreen canvas.
There is a large speed-optimization in here, called "blitting", which basically copies over only the parts that have changed, and reuses the old image.
There's a lot more to it than that, and there are a lot of caveats, these days, because of all of the special-effects we add, but there it is.
The second part of your question has to do with a concept called "instancing".
Instancing is similar to blitting, but while blitting is about only redrawing what's changed, instancing is about drawing the exact same thing several times in different places.
Say you're painting a forest in Photoshop.
You've got two options:
Draw every tree from scratch.
Draw one tree, copy it, paste it all over the image.
The downside of the second one is that each "instance" of the image looks exactly the same.
If your "template" image changes colour or takes damage, then all instances of the image do, too.
Also, if you had 87 different tree variations for an 8000 tree forest, making instances of them all would still be very fast, but it would take more memory, because you now need to save 87x more images than when it was just one tree, to reference on every draw call.
The upside is that it's still much, much faster.
To answer your specific question about X circles, versus instancing 1 circle:
Yes, it's still going to be a lot faster.
What a "lot" means, though, will change based on a lot of different things, because now you're talking about browsers on PCs.
How strong is the PC?
How good is the videocard?
How large is the canvas in software-pixels (not CSS pixels)?
How large are the circles? Do they have alpha-blending?
Is this written in WebGL or software?
If software is the canvas compositing in hardware mode?
For a typical PC, you should still be able to hit 60fps in Chrome, drawing 20 circles, I think (depending on what you're doing to them... ...just drawing them onscreen, every frame is simple), so in this case, the instances are still a "lot" faster, but it's not going to matter, because you've already passed the performance-ceiling of Canvas.
I don't know that the same would be true on phones/tablets, or battery-powered laptops/netbooks, though.
Yes, transferring from an offscreen canvas is faster than even primitive drawings like an arc-circle.
That's because the GPU just copies the pixels from the offscreen canvas (not much CPU effort required)
I am working on a game that uses HTML5 canvas 2D context drawing on a Chromecast device (which doesn't have hardware acceleration). I've noticed that drawing two objects in one frame will trigger a repaint of the entire region that contains both of them. As a "worst-case", imagine that I want to only change the color of the top-left and bottom-right pixels of a large canvas element. If I use two one-pixel fillRect calls to do this, it (WebKit/Blink, at least) will mark the entire canvas dirty, triggering a very expensive paint operation. I believe this should link to the code that performs this logic in Chromium:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/HTMLCanvasElement.cpp&l=218
Is there any way to convince the browser to actually perform two small paint operations instead of one (excessively) large one? Or would this always be slower, despite the fact that it's re-drawing significantly less? I have tried putting the elements on different canvas elements layered on top of each other, but the browser still seems to catch it and batch them together (at least as shown by the repaint regions in DevTools).
As far as I know, currently you can't do much better than that; one main drawback is that double buffering is not implemented either, which would have improved the performance. We will be seeing improvements in these areas moving forward.
I am starting to get a grasp of the HTML canvas and I wanted to know if it is encouraged to use optimization techniques. In games for example, is it encouraged to use bounding boxes and only redraw the portion of the screen that needs redrawing, or do people just blindly redraw everything. I ask this b/c I am creating a new engine for canvas and imposing bounding boxes complicates things greatly (ie. the user no longer has the freedom to quickly draw things to the stage).
Absolutely, it's almost always better to draw only what has changed on the screen at any one time. Attempting to draw everything causes unnecessary rasterisation of the images being drawn into one output image, when it's not even going to change on the screen.
In a small game I made a year ago, I was drawing a 2D array of tiles on the screen and getting around 15 frames per second. When I changed it to draw only the tiles visible on the screen, it was an amazing improvement. It will improve in this circumstance too.
I hope my English is good enough.
The Problem:
I am developing some canvas game, using context2d. I did a perfomance test to see how well canvas render and stuff.
For painting, the method drawImage was used with some 50x50 jpg preloaded in memory at start.
My test was to instantiate a lot of logic square 50x50 objects moving random in the canvas
with no collission just to see the fps.
main loop was done with interval.
The problem, i noticed low fps when about 3000 random 50x50 on the screen, well i know the more you render, the less framerate. But i wanna ask something.
The question:
Is a good idea render every logic object in the canvas screen alone?
For example, with no collision, if i overlap two 50x50 in the same position, or almost the same position, the visible output is something lesser than (50·50)2 pixels, but i am drawing (50·50)2 pixels using drawimage for each element in the main loop.
Hope you guys understand the problem and the question.
Render alternatives? some logic techniques to archieve this instead of rendering every object alone?
I understand what you are asking, you are asking maybe you should try and rendering the collisions so you don't have to draw twice. Well frankly, I think you'd be better off just drawing the second square on top of the first one, and I'll tell you why:
Your logic will probably take more actions to determine the amount of overlapping and drawing the more complex shape, then actually drawing it.
So in my opinion, you'd be better off not testing for collisions in this one.
People, correct me if I'm wrong.
Definitely just draw. The bitblt (pixel copy) is optimized and will certainly be faster than collision logic between sprites. However, the one exception is possibly testing for off-screen sprites. This is a fast test because you're only checking against the screen bounds, that is, if a sprite is off the screen. If you have 10,000+ sprites, and many are off-screen most of the time - for example when zoomed in - then the test is worth it.. If they're always on screen, then just draw.
Ok, so I'll try to be as descriptive as possible.
I'm working on a project for a client that requires a jibjab-style masking feature of an uploaded image.
I would like to be able to generate a database-storable object that contains anchor/control positions of a bezier shape, so I can pull it out later and re-mask the object. This all is pretty easy to do, except for one catch : I need to create the bezier object from a user-drawn outline.
So far, here's how I imagine the process going:
on mouse down, create a new sprite, beginFill, and moveTo mouse position.
on mouse move, lineTo an XY coordinate.
on mouse up, endFill.
This all works just great. I could just store the info here, but I would be looking at a GIGANTIC object full of tons of pretty useless x/y coordinates, and no way to really make fine-tuning changes outside of putting handles on every pixel. (I may as well give the end user a pencil tool...)
Here's what I'm thinking as far as bezier curve calculation goes :
1: Figure out when I need to start a new curve, and track the xy of the pixel on this interval. I'm imagining this being just a pixel count, maybe just increment a count variable per mouse move and make a new one every x pixels. The issue here is some curves would be inaccurate, and others unnecessary, but I really just need a general area, not an exact representation, so it could work. I'd be happier with something a little smarter though.
2: take each new x/y, store it as an anchor, and figure out where a control would go to make the line curve between this and the last anchor. this is where I get really hung up. I'm sure someone has done this in flash, but no amount of googling can seem to help me out with the way to get this done. I've done a lot of sketching and what little math I can wrap my brain around, but can't seem to figure out a way of converting pixels to beziers.
Is this possible? All I really need is something that will get close to the same shape. I'm thinking about maybe only placing anchors when the angle of the next pixel is beyond 180 degrees in relation to the current line or something, and just grabbing the edge of the arc between these changes, but no matter how hard I try, I can't seem to figure out how to get this working!
Thanks for your help, I'll be sure to post my progress here as I go, I think this could be really useful in many applications, as long as it's actually feasible...
Jesse
It sounds like a lot of work to turn pixels into Bezier curves. You could try using something like the Linear least squares algorithm. http://en.wikipedia.org/wiki/Linear_least_squares
A different tact, could you have your users draw vector graphics instead? That way you can just store the shapes in the database.
Another cool method of converting raster to vector would be something like this iterative program: http://rogeralsing.com/2008/12/07/genetic-programming-evolution-of-mona-lisa/
Good luck
In my answer to this question I discuss using autotrace to convert bitmaps to beziers. I recommend passing your user drawing through this program on the server. Autotrace does a fantastic job of tracing and simplifying so there is no need to try and reinvent the wheel here.
Thanks for the answers, although I guess I probably should be more specific about the application, I'm really only needing an outline for a mask, so converting images to vectors or polygons, despite how cool that is, doesn't really fix my issue. The linear least squares algorithm is mega cool, I think this might be closer to what I'm looking for.
I have a basic workaround going right now, I'm just counting mouse moves, then every X (playing with it to get most desirable curve) moves, I grab the xy position. then, I take every other stored xy, and turn it into an anchor, the remaining xys are turned into controls. This is producing somewhat desirable results, but has some minor issues, in that the speed at which the mask is drawn effects the number of handles, and it's really just getting a general area, not a precise fit.
Interestingly, users seem to draw slower for more precise shapes, so this solution works a lot better than I had imagined, but it's not as nice as it could be. This will work for the client, so although there's no reason to pursue it further, I like learning new things, and will spend some off the clock time looking into linear least equations and seeing if I can drum up a class that will do these computations for me. If anyone runs across some AS3 code for this type of thing, or would like some of mine, let me know, this is an interesting puzzle.