In defense of • Hacker News Board

Re: In defense of <canvas>

#11

Post by kevingadd » Mon, May 06, 2013, 5:21 PM UTC

comex wrote: post #8

Canvas may be pretty well optimized by now, but it's far from perfect. When I was using it a few months ago, I needed to draw into a temporary context then draw the result into the main canvas, because of unusual composite operations. This worked well on most browsers, but Safari incurred a massive slowdown which, according to Instruments, was largely caused by time spent in memcpy and some sort of surface locking. I…

Yeah, my experience roughly matches yours. In practice Firefox, IE and Chrome currently have very fast 'fast paths' for Canvas, but if you hit the slow path - some operation that isn't optimized - you can see a 5x performance hit, or a 50x performance hit. And because Canvas's feature set is so limited your only workaround is usually to do it in software. Composite operations are definitely not consistently optimized across browsers.

It's worse on mobile, where for some reason way less effort has gone into hardware accelerated canvas - there I think you may just be stuck using WebGL.

Re: In defense of <canvas>

#12

Post by coldtea » Mon, May 06, 2013, 5:32 PM UTC

>On Soundslice, we're drawing guitar-chord charts completely on the fly (again, see an example), which is a relatively involved drawing routine -- and it's still near-instant performance. That's across all modern browsers (Chrome, Safari, Firefox and IE 10).

OK, let me get this out of the way. Drawing guitar tabs on the fly is not by a long shot an "involved drawing routine".

If that's his standard for canvas performance, then sure, canvas is plenty of fast for that.

(I don't say it's not a quite complex algorithm to position and determine the guitar tabs: I say that it's not that graphically demanding to draw them. It's easier on the canvas/CPU than even the tamest of platform scrollers for example).

Re: In defense of <canvas>

#13

Post by simonsarris » Mon, May 06, 2013, 5:42 PM UTC

I've done a large amount of canvas work over the past years, especially work with improving canvas performance (one of the articles on my site is linked-to by this article). What follows is fairly self-promotional, but relevant to the topic if you're interested in canvas performance.

I've been compiling canvas performance tips for two years now, and have a full-color (syntax highlighting and images) book coming out very soon[1] with its own Canvas performance chapter at about ~40 pages. The book has about ~200 pages total of Canvas tips, oddities and tutorials. These aren't fluff, I don't take pages and pages to re-implement stuff like gravity for a game example. I tried to keep it pertinent and pure.

If you're interested in Canvas, please give it a look[1]. The book will be out in June or July.

And if you're interested in getting help for Canvas, come to StackOverflow! Back when I had free time, if you asked a question on SO about canvas there was a +10% chance that I was the one who answered it. I've been too busy to participate in the last year, but I'm just beginning to come into some free time again these days, and there are several other wonderful people who also hound the canvas tag.

Also, if you're looking for live help with Canvas issues, give the StackOverflow JavaScript room a try[2]. They're very friendly if you are, and always love interesting (read: not jQuery) questions.

[1] http://www.amazon.com/dp/0672336278/

[2] http://chat.stackoverflow.com/rooms/17/javascript

Re: In defense of <canvas>

#14

Post by thetabyte » Mon, May 06, 2013, 5:46 PM UTC

babuskov wrote: post #7

Should you be using canvas directly? I'm currently writing my 3rd HTML based game, and I'm so tired of using jQuery and DOM directly, so I want to replace it with canvas. Game is a turn-based strategy, so performance is not an issue (there will be some animations, but rare). I looked at the canvas and then at a lot of 2D libraries that can speed the development and prevent me from reinventing the wheel. I'm overwhelm…

Well, no tips, but I do have a question:

I'm a web dev who's been looking to start trying game development, particularly with canvas. However, I've hit a huge wall with any type of graphics programming. Have you found any particularly good resources while trying to learn canvas, or graphics programming in general? Or anyone else here? If you have something feel free to email it to mrjordangoldstein at gmail.com if it doesn't seem strictly relevant to this thread—and thanks!

Re: In defense of <canvas>

#15

Post by visualR » Mon, May 06, 2013, 5:50 PM UTC

The only thing slow about Canvas I've found is when the canvas area needs to be resized : i.e. canvas.height or canvas.width changes. Drawing itself hasnt been an issue for me.

Re: In defense of <canvas>

#16

Post by CamperBob2 » Mon, May 06, 2013, 5:54 PM UTC

kevingadd wrote: post #9

babuskov wrote: post #7

Should you be using canvas directly? I'm currently writing my 3rd HTML based game, and I'm so tired of using jQuery and DOM directly, so I want to replace it with canvas. Game is a turn-based strategy, so performance is not an issue (there will be some animations, but rare). I looked at the canvas and then at a lot of 2D libraries that can speed the development and prevent me from reinventing the wheel. I'm overwhelm…

I recommend using canvas directly unless you specifically need features offered by a wrapper (for example, Cocos2D provides a scene graph of sorts). Canvas has enough weird performance problems that you don't need a library adding more on top.

OTOH, if the authors of the library know more about the fast rendering paths on various browsers than you do, they can actually give you better performance than "coding to the metal," so to speak.

Re: In defense of <canvas>

#17

Post by euroclydon » Mon, May 06, 2013, 6:00 PM UTC

babuskov wrote: post #7

Should you be using canvas directly? I'm currently writing my 3rd HTML based game, and I'm so tired of using jQuery and DOM directly, so I want to replace it with canvas. Game is a turn-based strategy, so performance is not an issue (there will be some animations, but rare). I looked at the canvas and then at a lot of 2D libraries that can speed the development and prevent me from reinventing the wheel. I'm overwhelm…

If you want a scene graph, have you evaluated fabric.js? It's a popular canvas library, providing mouse events, and import/export to SVG.

Re: In defense of <canvas>

#18

Post by normanv » Mon, May 06, 2013, 6:03 PM UTC

If you are doing a lot of canvas drawing, you should really check out WebCode (http://www.webcodeapp.com/). It's a drawing app that automatically writes the canvas JavaScript code for you.

Re: In defense of <canvas>

#19

Post by mAritz » Mon, May 06, 2013, 6:03 PM UTC

simonsarris wrote: post #13

I've done a large amount of canvas work over the past years, especially work with improving canvas performance (one of the articles on my site is linked-to by this article). What follows is fairly self-promotional, but relevant to the topic if you're interested in canvas performance. I've been compiling canvas performance tips for two years now, and have a full-color (syntax highlighting and images) book coming out v…

Any chance for an ebook edition? I'm quite interested but don't really want to order a paperback edition from overseas.

Re: In defense of <canvas>

#20

Post by city41 » Mon, May 06, 2013, 6:03 PM UTC

babuskov wrote: post #7

Should you be using canvas directly? I'm currently writing my 3rd HTML based game, and I'm so tired of using jQuery and DOM directly, so I want to replace it with canvas. Game is a turn-based strategy, so performance is not an issue (there will be some animations, but rare). I looked at the canvas and then at a lot of 2D libraries that can speed the development and prevent me from reinventing the wheel. I'm overwhelm…

I recommend checking out my Breakouts project, which is aimed at answering your question: http://city41.github.io/breakouts. It's the same idea as TodoMVC but for js game engines.