DOM vs Canvas

1,300 views
Skip to first unread message

Søren Bramer Schmidt

unread,
Jun 16, 2012, 4:18:55 PM6/16/12
to craf...@googlegroups.com
Our current canvas implementation uses redraw regions to improve performance. This makes it quite difficult to draw custom stuff to the canvas (lines etc.), so i usually only use the canvas to display sprites and spriteAnimations.

The problem is that for this kind of work canvas is often slower than DOM entities. Therefore I am thinking there might be a better way for Crafty to decide what to draw on canvas, and what to draw using DOM elements.

To get a better understanding of this, I would like to know in which ways you are using canvas. Are you using the Crafty managed canvas, or your own canvas object? what are you rendering? what does canvas provide over DOM elements?

Thank you

witali mik

unread,
Jun 16, 2012, 5:38:08 PM6/16/12
to craf...@googlegroups.com
Personally for me iam not need Canvas, just DOM is enought. The real difference what canvas can do and dom not is Drawing freeshapes or draw particle effects. on the otherhand canvas cannot display offscreen like a DOM element can.

i dont know what is more performant, animations which using canvas or animations with HTML and background image. maybe you can make a small example of some animations in DOM and Canvas screen without Crafty, just pure JS? and in Fullscreen mode?

i think if we would just allow Canvas, we could use Flash Canvas and crafty would support IE and Older browsers.

but if we would not support DOM anymore, we were not able to use jQuery. i think it would be a good idea to Choose Canvas + Flash Canvas Support but also leave DOM inside just restrict some functions with exceptions.

Søren Bramer Schmidt

unread,
Jun 16, 2012, 5:52:19 PM6/16/12
to craf...@googlegroups.com
For Crafty entities with sprites and spriteAnimations DOM is in most cases the most performant rendering system. For example, running the asteroids example full screen on a 24 inch screen lag is very noticeable on FF and IE10. If i change to DOM it runs smoothly.
So my idea (well, Matt Petrovic's idea actually) is to always use DOM rendering in this case. Before we go ahead and do this i would like some more input though.

witali mik

unread,
Jun 17, 2012, 3:58:56 PM6/17/12
to craf...@googlegroups.com
Ok if you use DOM only you also can use CSS animations with @transform, it would be even more performant. so in what cases we would need and use Canvas? particles? free drawing?

witali mik

unread,
Jun 25, 2012, 2:37:19 AM6/25/12
to craf...@googlegroups.com
I think, removing canvas will be death for CraftyJS. instead of using DOM only i would suggest to improve canvas performance. there are some tricks which are currently not implemented in Crafty, for example prerender.

http://en.wikipedia.org/wiki/Display_list

we could create a "DisplayList" component for Static(not animations) images/shapes and instead of ctx.moveTo/lineTo just copy the prerender canvas to main canvas. then multiple layers would improve canvas perofrmance as well. iam sure if we do enought performance improvements, we will get canvas faster than DOM (in complex games)

kaikomai

unread,
Jun 27, 2012, 4:02:45 PM6/27/12
to craf...@googlegroups.com
I do not think the answer is to decide whether or not to use DOM or Canvas. I use both options in my development depending on my work and I would like to keep this ability.

The DOM slows down when you have lots of small entities (like Particles or Animated Sprites) - because the DOM has to deal with Objects as opposed to just straight image data in canvas. And if you want to do Free-drawn/vector graphics - this is where Canvas shines.
I also do a lot of image tinting to give feedback to users in my games - DOM cannot do this without an extra sprite. Canvas does this easily.
Image manipulation in general is just better with Canvas - and it is more standard across browsers as opposed to CSS3.

Canvas in Crafty could definitely use some performance improvements: pre-rendering backgrounds/images/anything large literally improves Canvas performance by ~400%:
http://io-2011-html5-games-hr.appspot.com/#46 this specific slide (and the few after it) detail how Canvas actually can render "off-screen". this could be applied to Tinted Images, the Color component, as well as repeating-backgrounds (this is a major performance area) or just anything that is static and on the screen for a long time. UI cached in canvas is another example.

Canvas can also take advantage of WebGL:https://github.com/corbanbrook/webgl-2d - I haven't tried this with Crafty but on other JS game engines - this improves canvas performance by some 20-30%. Perhaps a plugin could be created. Its really only a few lines of code to get this working.

I find it very odd that Canvas is slower than DOM in Crafty because with most other JS game engines, the opposite is true, at least when you get more objects on the screen.
http://www.themaninblue.com/writing/perspective/2010/03/22/ There are numerous benchmarks that show that when utilized correctly, canvas should be superior on the desktop. Canvas should also be able to get around 15-30FPS on iOS4+ but I cannot even get above 10 with Crafty.

And while DOM is faster at the moment, I believe it could also be improved. There was a post on github i think in the "mobile support" issue that details how DOM performance in Crafty duplicates screen-draws because of how the style elements are updated. Also the delta-based-time structure planned for future releases could potentially improve animation/fps if applied correctly.

TL;DR; Canvas should be faster, but for whatever reason in Crafty, it is slower. I suggest improving canvas before making any decisions about which to draw.

Daniel Skiles

unread,
Aug 10, 2012, 4:25:02 PM8/10/12
to craf...@googlegroups.com
I apologize for responding to an older thread, but I thought I'd take a moment to provide an anecdote about DOM vs Canvas performance.

The game that I am writing uses a large number of sprites and entities, with ~400 static sprite entities, one animated sprite entity, and a few dozen colored-point "particles" at any given time.  The game stage is a single screen with a static viewport.

Using all DOM entities caused some responsiveness issues, especially as the number of active entities at any given time started to creep up.

Switching the ~400 static sprite entities and the "particle" entities from DOM to Canvas reduced CPU load by roughly 50% and subjectively improved responsiveness for the end user by a considerable margin.  There was a tradeoff in considerably increased memory usage, but in this case that was acceptable.

TL;DR:  Canvas might be a good choice if you have Too Much Stuff on the screen.
Reply all
Reply to author
Forward
0 new messages