In defense of
holovaty.com
In defense of
1–10 of 64 posts
Re: In defense of <canvas>
#2These seem like the same sorts of guidelines you want to follow when writing native apps too. It seems fair to treat a element like a CALayer.
Re: In defense of <canvas>
#3The major problem with the vs WebGL is excessive amounts of draw calls. You can't create ship a display list/vertex buffer, and so there's a ton of JS->Native Browser binding calls. They've recently changed this with CanvasRenderingContext2D version 2(adding Path objects). None-the-less, right now, it's much faster to use WebGL and layer over a 2d canvas for text or curves.
Re: In defense of <canvas>
#4These seem like the same sorts of guidelines you want to follow when writing native apps too. It seems fair to treat a element like a CALayer.
There's actually a pretty deep connection there. In Firefox, a canvas typically becomes a separate CanvasLayer in the layers stack. The layers implementation in Firefox is very similar to Core Animation—they're composited together using OpenGL (or Direct3D on Windows), animations can happen on the layer tree, scrolling is performed on the layer tree, and so on.
Re: In defense of <canvas>
#5For 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 able to maintain 60fps or higher.)
There's certainly plenty of reasons to make native apps. But I was pleasantly surprised by canvas performance, personally.
Re: In defense of <canvas>
#6re: canvas stacking, check out http://kineticjs.com/
Re: In defense of <canvas>
#7Should 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 overwhelmed with options. From some 20+ I investigated I narrowed the list down to these:
- CanvasEngine
- Cocos2D
- MelonJS
- Quintus
- EaselJS
Re: In defense of <canvas>
#8Canvas 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'm not sure why memcpying relatively small images on a powerful CPU was using so much time, but a more performant implementation would use render-to-texture and not do a round trip through the CPU, and whatever their implementations other browsers had no such problems. It was slow enough - just drawing a few 300x300 or so images at 60fps! - that on x86 it might well have ended up faster to just construct the frame in JS using array buffers; unfortunately, I was also trying to target Safari for iOS.
Considering that Canvas also has hard limits on what sort of effects you can implement with it, I hope WebGL is supported in Safari and IE soon.
Re: In defense of <canvas>
#9Should 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.
Re: In defense of <canvas>
#10Should 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…
Games get dull without animation