Develop Reference

Javascript - Large number of rendered objects

I'm building a web app based on javascript/jQuery and php, and I need to render and manage (e.g. have the user drag/drop, resize, etc) a large number (20,000+) of drawn objects on a web page and am looking for a recommendation in terms of approach/libraries to use, mainly to get an idea of how to do this whilst keeping page performance acceptable.
The objects are simple geometric shapes (rectangles, circles, squares, etc) that I will need to attach event handlers to and be able to move/re-size. Shape attributes will be based on properties of javascript objects and I'll need to change the shapes based on the javascript object properties and vice versa.
The canvas area is likely to be quite large (not sure if this will affect performance?) although not all objects will be 'visible' on the page, but must be able to scroll within a div (using overflow, etc) around the full canvas. I have built something for test purposes using jQuery SVGDOM which works well when I have a couple of hundred objects, but the page grinds to a halt when I go over 1000 objects.
What I like about svgdom is the way it fits nicely with jQuery for referencing the DOM objects (for event handlers, etc), but am willing to (try to) develop more complex code if I need to in order to be able to address the larger number of objects that svgdom doesn't seem happy with from a performance perspective.
Any suggestions for how to do this?

I think you need to look into webGL, which renders using the GPU. A good framework for that is three.js.
Still, to manage your expectations: making 20k objects interactive really a big challenge and might need some smart caching system to fake it. if you target mobile devices too, I would say your goal is way too ambigious. I am sometimes already happy if 100 objects run/move smooth.

I'm taking as the answer to my original question that it is not practical to display/manage the number of objects that I need on a single page whether SVG or directly to the canvas.
So my approach must be to reduce the number of objects displayed at any given time - now I just need to figure out what the best way to do this is...

Should I use multiple canvases (HTML 5) or use divs to display HUD data?

I am in process of making a game where the health bar (animated) and some other info represented visually like some icons showing the number of bombs the player has etc. Now, this can be done both in canvas (by making another canvas for info that sits over the main canvas, or it can be done using many divs and spans with absolute positioning. This is my first time in making a browser based game so if any experienced people view this, tell me what you recommend. I would like to know that which method would be faster.
The game will also be running on mobile devices. Thanks!

There is no straighforward answer and I suggest you do FPS testing with different browser how it plays out for your use case. If you do not wish to go such in-depth I suggest you simply draw the elements inside canvas and if you need to hide them then leave out drawHUD() call from your rendering loop.
For HTML HUD overlay on <canvas> the following factors should be considered
Can the web browser compositor do hardware accelerated <canvas> properly if there are DOM elements upon the canvas
HTML / DOM manipulation will be always slower than <canvas> operations due to inherited complexity dealing with DOM elements
<canvas> pixel space stays inside <canvas> and it might be difficult to have pixel-perfect aligment if you try to draw elements on <canvas> outside the canvas itself
HTML offers much more formatting options for text than canvas drawString() - is HTML formatting necessary

Use the canvas. Use two canvases if you want, one overlaid over the other, but use the canvas.
Touching the DOM at all is slow. Making the document redo its layout because the size of DOM elements moved is very slow. Dealing with the canceling (or not) of even more events because there are DOM items physically on top of the canvas can be a pain and why bother dealing with that?
If your HUD does not update very often then the fastest thing to do would be drawing it to an in-memory canvas when it changes, and then always drawing that canvas to the main canvas when you update the frame. In that way your drawHud method will look exactly like this:
function drawHUD() {
// This is what gets called every frame
// one call to drawImage = simple and fast
ctx.drawImage(inMemoryCanvas, 0, 0);
}
and of course updating the HUD information would be like:
function updateHUD() {
// This is only called if information in the HUD changes
inMemCtx.clearRect(0, 0, width, height);
inMemCtx.fillRect(blah);
inMemCtx.drawImage(SomeHudImage, x, y);
var textToDraw = "Actually text is really slow and if there's" +
"often repeated lines of text in your game you should be" +
"caching them to images instead";
inMemCtx.fillText(textToDraw, x, y);
}
Since HUDs often contain text I really do urge caching it if you're using any. More on text performance here.

As others have said, there is no universally best approach, as it depends on the specifics of what you need to render, how often, and possibly what messaging needs to happen between graphical components.
While it is true the DOM reflows are expensive, this blanket warning is not always applicable. For instance, using position:fixed; elements avoids triggering reflows for the page (not necessarily within the element if there are non-fixed children). Repaint is (correct me if this is wrong) expensive because it is pixel pushing, and so is not intrinsically slower than pushing the same number of pixels to a canvas. It can be faster for some things. What's more, each has certain operations that have performance advantages over the other.
Here are some points to consider:
It's increasingly possible to use WebGL-accelerated canvas elements on many A-grade browsers. This works fine for 2D, with the advantage that drawing operations are sent to the GPU, which is MUCH faster than the 2D context. However this may not be available on some target platforms (e.g., at the time of this writing, it is available in iOS Safari but not in the iOS UIWebView used if you target hybrid mobile applications.) Using a library to wrap canvas can abstract this and use WebGL if its available. Take a look at pixi.js.
Conversely, the DOM has CSS3 animations/transitions which are typically hardware-accelerated by the GPU automatically (with no reliance on WebGL). Depending on the type of animation, you can often get much faster results this way than with canvas, and often with simpler code.
Ultimately, as a rule in software performance, understanding the algorithms used is critical. That is, regardless of which approach used, how are you scheduling animation frames? Have you looked in a profiler to see what things take the most time? This practice is excellent for understanding what is impacting performance.
I've been working on an app with multiple animations, and have implemented each component both as DOM and canvas. I was initially surprised that the DOM version was higher performant than the canvas (wrapped with KineticJS) version, though I know see that this was because all the animated elements were position:fixed and using CSS (under the hood via jQuery UI), thereby getting GPU performance. However the code to manage these elements felt clunky (in my case, ymmv). Using a canvas approach allows more pixel-perfect rendering, but then it loses the ability to style with CSS (which technically allows pixel-perfect rendering as well but may be more or less complex to achieve).
I achieved a big speed up by throttling the most complex animation to a lower framerate, which for my case is indistinguishable from the 60fps version but runs smooth as butter on an older iPad 2. Throttling required using requestAnimationFrame and clamping calls to be no more often than the desired framerate. This would be hard to do with CSS animations on the DOM (though again, these are intrinsically faster for many things). The next thing I'm looking at is syncing multiple canvas-based components to the same requestAnimationFrame loop (possibly independently throttled, or a round-robin approach where each component gets a set fraction of the framerate, which may work okay for 2-3 elements. (Incidentally, I have some GUI controls like sliders that are not locked to any framerate as they are should be as close to 60fps as possible and are small/simple enough that I haven't seen performance issues with them).
I also achieved a huge speed boost by profiling and seeing that one class in my code that had nothing to do with the GUI was having a specific method called very often to calculate a property. The class in question was immutable, so I changed the method to memoize the value and saw the CPU usage drop in half. Thanks Chrome DevTools and the flame chart! Always profile.
Most of the time, the number of pixels being updated will tend to be the biggest bottleneck, though if you can do it on the GPU you have effectively regained all the CPU for your code. DOM reflows should be avoided, but this does not mean avoid the DOM. Some elements are far simpler to render using the DOM (e.g. text!) and may be optimized by the browser's (or OS's) native code more than canvas. Finally, if you can get acceptable performance for a given component using either approach (DOM or canvas), use the one that makes the code simplest for managing that type of component.
Best advice is to try isolated portions in the different approaches, run with a profiler, use techniques to over-draw or otherwise push the limits to see which approach can run fastest, and do NOT optimize before you have to. The caveat to this rule is the question you are asking: how do I know in advance which technical approach is going to allow the best performance? If you pick one based on assuming the answer, you are basically prematurely optimizing and will live with the arbitrary pain this causes. If instead you are picking by rapid prototyping or (even better) controlled experiments that focus on the needs of your application, you are doing R&D :)

Browserquest displays their HUD using HTML elements, which has the benefit that you don't have to worry about redrawing etc. (and the performance will be pretty good, given that the entire browser engine is optimized to render the DOM pretty fast.
They (browserquest) also use several layered canvas elements for different game elements. I don't know the exact structure, but I guess that on which canvas an element is displayed depends on how often it needs to be redrawn.

HTML 5 Canvas vs Divs for scrolling pane

I'm making an TV Guide. See http://i.tv/guide for an example implementation using Canvas.
I need to make lots of little boxes representing each show. I need to be able to scroll them around, both vertically (channels) and horizontally (time). To make it with Canvas, my understanding is that the only way to implement scrolling is to intercept the correct events, and redraw the canvas smoothly with new offsets many times a second.
If I were to use divs, I could slap scrollbars on it and let it scroll normally. I could position them once, and let the scrolling move them around, rather than re-calculating their new offsets.
Which should I pick for this kind of project? If I use divs will it be too slow? Some lineups have 500 channels. I want to display up to 4 hours at once.
Thanks!

I would strongly recommend using plain HTML in preference to canvas, for interactive elements. Apart from the speed issue (divs are usually going to be faster than drawing it all manually yourself), HTML is designed to offer accessibility and usability features for free, which you'd have to do a lot of work to get even partially from canvas.
The canvas-based guide as linked has the following drawbacks:
very slow to render/scroll, for me;
impervious to keyboard navigation;
no HTML link actions (like middle-click-link-to-open-in-new-tab or right-click-bookmark);
text not copy/pastable;
a dead loss for accessibility tools like screen-readers;
reduced browser compatibility;
invisible to search engines.
Use canvas for pretty graphical and interactive effects you can't achieve with plain HTML. To be honest I don't even see any of that on i.tv's site; I have no idea why they have implemented it in this seemingly-crazy way.

Doing it with DIV's wont have issues with speed. Browsers rendering engines are built to render elements. DOM rendering is faster than canvas rendering in a lot of cases, take isogenicengine they use DOM based rendering to render thousands of elements to make games You should implement it based on your technical ability. Both technologies will be able to do what you want. Personally I would choose canvas but I see no issue with DOM rendering.
Good Luck.

Recommended techniques for smoother image transitions

I am building a slideshow, and I'd like to include smooth (subpixel) image transitions involving sliding and resizing, like for example a Ken Burns effect.
I see that people use various techniques. I'd be interested to know which ones are considered the best approach today, and if any of these are just urban myths that actually bring no improvement:
css transitions
JavaScript requireanimationframe
image embedded in a canvas element
other?
Note: I undertand that some of these techniques are not supported in older browsers. My question is for thwe most recent versions (IE9, Firefox 5, etc.).

I think CSS transitions could be a good answer to the major parts of the effects you want.
CSS transitions are designed for changing smoothly between two states of an element.
For ken burns effect It could be accomplish by doing transitions of width on two pictures that are on absolute position for example.
Using Javascript to animate can be a bit laborious and if you want to manipulate dom on each frame it can be heavy for performance.
I also think canvas is not the best solutions because canvas element is not dynamically scalable without problem (performance particulary).

See the following post on Javascript Performance Optimizations:
It outlines different performance techniques across 5 broad subjects:
Avoiding interaction with host objects (DOM)
Managing and Actively reducing your Dependencies
Disciplined event binding
Maximising the efficiency of your iterations
Becoming friends with the JavaScript lexicon
The ones that apply the most to smooth image transitions are in sections 1, 3 and 4, particularly the use of pointer references to browser DOM objects (so you dont have to traverse the DOM multiple times), applying DOM changes in batches, and optimizing the efficiency of your iterations.
However all 5 sections are useful for creating a highly responsive UI

What's the best solution for rendering a javascript game in Browser (complete viewport)

I think there are two diffrent solutions for the problem:
1) First the solution shown by aves Engine, which renders the whole game with html elements and external stylesheets e.g. CSS3 transfomations. Pro's are that the event-handling is much easier when working with div's than by rendering on canvas.
2) Like isogenicengine.com shows you could render the game on html5 canvas element. Mabye that's the better solution, because rendering on canvas is the way that millions of 2D-games were written before and in future the industry will optimize the drawing methods e.g. with hardware acceleration. At the moment the contra is that rendering on canvas is slow if you would like to render in fullscreen. If you would like to render only in a specific area of 200x200px that's okay, but in fullscreen you get stuck with a framerate of 10fps.
What do you think is the better way to create a game for the web?
Thanks for your opinion!
PS: If you have some articles about the topic please paste some links

I don't think it's a clear one size fits all kind of thing. I really think it depends on what you want to do with your game.
If you are doing a lot of vector graphic manipulation, perhaps canvas is a better choice vs engine like aves. For tiled based, maybe aves will work better.

You can render fast on fullscreen canvas if you're clever about only re-rendering dirty regions. But if your whole canvas needs to change every frame this obviously isn't going to help much.

I've spent alot of time recently looking into this issue and my conclusion is pretty simple.
Use HTML Elements, lets say that HTML5 actually makes progress and in one year the major browser support it. How long does it then take to get the general user base of the web on the latest browser (IE6 still has a choke hold in some sectors). So making the game available to as many people as possible is key! (In my mind anyways)
If however, your looking to learn and develop, go with canvas.