Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defense of

holovaty.com

Post reply on HN
Print view View original

41–50 of 64 posts

Re: In defense of <canvas>

#41

Post by simonsarris »

VMG wrote: post #39
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…

Ha! Caught you not mentioning your blog posts while I was adding this comment to my "canvas performance" bookmark list and saw a familiar name. http://simonsarris.com/blog/tag/performance

Because of the book, I haven't been able to blog about canvas performance in a long time! But very soon there will be a return to (canvas and performance) blogging.

Re: In defense of <canvas>

#42

Post by krallja »

I really like this Soundslice canvas app. Why didn't Soundslice use Scalable Vector Graphics? CSS Animations would replace a whole heap of code: the entire requestAnimationFrame callback, for example, would be eliminated. Text rendering would be handled by the browser, instead of taking the performance hit of being rendered to the canvas bitmap every frame, so text rendering caching would not be necessary. Element stacking would be handled by the browser's built-in compositor. You wouldn't have to think about crazy microoptimizations like grouping fillStyles together. SVG can easily be accelerated by the browser, since you're describing intent instead of specific procedures, unlike Canvas' immediate mode drawing. Finally, vector graphics aren't locked to 72dpi, so they look amazing on a MacBook Pro Retina or other device with high DPI (unlike the canvas implementation, which looks pretty chunky!)

Re: In defense of <canvas>

#43

Post by Jack000 »

adrianh wrote: post #37
Jack000 wrote: post #36

the soundslice example might be a bit flawed. It's fast for a canvas app but not even close to "native magic" on my pc using chrome. I feel like some sort of html luddite, but am I the only one who preferred flash/actionscript3 to canvas/javascript? I get that the web should be open, but beyond the idealism the flash drawing tools were much better. I feel that the criticisms currently levied against flash will come u…

Hey, thanks for the feedback! What were you doing with Soundslice when it felt slow -- were you zoomed out (such that there were a ton of annotations visible on the page)? Or was it just slow in general, even when it was zoomed in?

it's quite fast actually, I'm very impressed. I think what I was trying to say is that it doesn't feel native at times, but it's difficult to articulate why. Maybe I'm just conditioned to use webapps differently, and pick up on cues like slightly lagging cursors and such.

Re: In defense of <canvas>

#44

Post by adrianh »

Jack000 wrote: post #43
adrianh wrote: post #37

Earlier quoted context omitted.

Hey, thanks for the feedback! What were you doing with Soundslice when it felt slow -- were you zoomed out (such that there were a ton of annotations visible on the page)? Or was it just slow in general, even when it was zoomed in?

it's quite fast actually, I'm very impressed. I think what I was trying to say is that it doesn't feel native at times, but it's difficult to articulate why. Maybe I'm just conditioned to use webapps differently, and pick up on cues like slightly lagging cursors and such.

Ahh, cool -- got it. Thanks!

Re: In defense of <canvas>

#45

Post by adrianh »

krallja wrote: post #42

I really like this Soundslice canvas app. Why didn't Soundslice use Scalable Vector Graphics? CSS Animations would replace a whole heap of code: the entire requestAnimationFrame callback, for example, would be eliminated. Text rendering would be handled by the browser, instead of taking the performance hit of being rendered to the canvas bitmap every frame, so text rendering caching would not be necessary. Element st…

Hey -- I didn't spend much time exploring SVG, to be honest. It could very well be faster!

And you're right that it would be much better on retina screens. I've had it on my to-do list to make the canvas implementation take the device pixel ratio into account, but it hasn't been a huge priority.

Re: In defense of <canvas>

#46

Post by TimJRobinson »

I've found canvas to be more than powerful enough for my 2d game http://www.towerstorm.com even with hundreds of animated minions and thousand of bullets moving across the screen. I'm using the impactjs engine which has made things easier as it has a few of these tweaks built in.

Multiple canvas layers is an awesome idea, as things such as the game background never change so it's a waste re-rendering it every frame. will try it out soon and see how it goes.

Re: In defense of <canvas>

#47

Post by lotyrin »

krallja wrote: post #42

I really like this Soundslice canvas app. Why didn't Soundslice use Scalable Vector Graphics? CSS Animations would replace a whole heap of code: the entire requestAnimationFrame callback, for example, would be eliminated. Text rendering would be handled by the browser, instead of taking the performance hit of being rendered to the canvas bitmap every frame, so text rendering caching would not be necessary. Element st…

I don't know the answer here, but it's a solid trend. SVG just seems to get completely neglected. Sure if you're animating things and you're doing so in a world before CSS3 transitions, manipulating hundreds of attributes at 60fps in the DOM won't perform, but we're past that.

Re: In defense of <canvas>

#48

Post by takeoutweight »

kevingadd wrote: post #11
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…

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

Re: In defense of <canvas>

#49

Post by zimpenfish »

Well, I loaded the Super Mario Bros Soundslice, set it to scrolling, hit play, then put on my ear defenders as the MBP tried to commit fan-suicide. Maybe it's just a Firefoxism but normally only Flash makes the fans go that hard...

Re: In defense of <canvas>

#50

Post by andrewroycarter »

ebbv wrote: post #5

For me learning to use canvas was easy. But I had learned graphics programming when I was a kid messing with SCREEN 13 in QBasic. And a lot of the lessons I picked up then, apply to canvas today. I found canvas is actually a lot faster than I expected. I made a little graphical Roguelike that was drawing hundreds of sprites at 30fps in all modern browsers easily even on my iPhone (some browsers on some systems are ab…

Good memories! I learned to program making silly games on a crappy computer in QBasic :)
Post reply on HN