In defense of • Hacker News Board

Re: In defense of <canvas>

#61

Post by w0utert » Tue, May 07, 2013, 1:45 PM UTC

coldtea wrote: post #12

> 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 perfor…

I agree. I'm sincerely impressed by the Soundslice application, it's really awesome how the videos move along with the tab to show how every chord is played, and the UI is fast, responsive and easy to use. That said, I'm also inclined to say this particular application simply falls beyond the threshold where UI performance becomes an issue.

Re: In defense of <canvas>

#62

Post by obeattie » Tue, May 07, 2013, 2:00 PM UTC

I too have developed a pretty "serious" Canvas application that people actually use on a large scale, http://www.luckyvoice.com/sing

While I agree with your suggestions (caching is absolutely a must, as is batched rendering etc), but I think the real issue is the lack of good-quality canvas libraries that have the kind of breadth of functionality that their native counterparts have have. All of these "performance hacks" are certainly not unique to canvas, but what is is unique is the developer (user of these APIs) having to care about them. They should be abstracted away.

Libraries like Paper.js (which I've used and extended a lot) and EaselJS are bridging the gap, but they aren't there yet — either because they aren't feature-complete in the way that they need to be, they're buggy, and/or they don't seem to be getting enough community development (or in some cases, want it).

Re: In defense of <canvas>

#63

Post by Groxx » Tue, May 07, 2013, 5:05 PM UTC

takeoutweight wrote: post #48

kevingadd wrote: post #11

Earlier quoted context omitted.

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…

WebGL support on mobile is pretty rare. I think only a few browsers like Firefox mobile and Opera mobile support it.

Chrome as well. I forget if it has to be enabled in a flag / only on beta builds still, but it does work.

Re: In defense of <canvas>

#64

Post by Groxx » Tue, May 07, 2013, 5:10 PM UTC

hatu wrote: post #60

p0nce wrote: post #56

Canvas may need a lot of sweat to get some performance [1] but there is something it does really well. What strikes me is the lovely API. It just great to use it for charts, procedural UIs, etc... and it also somewhat work with games. [1] http://www.gamesfrommars.fr/demojsv2

Really? I thought the API was pretty silly compared to for example Flash Drawing API. Why doesn't it have circle(x,y,radius) for example?

because that's better suited for a library?