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

21–30 of 64 posts

Re: In defense of <canvas>

#21

Post by chris_engel »

thetabyte wrote: post #14
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…

Hey, you should visit http://html5gamedevs.com - we are an active community and I'm sure you will find help there :)

Re: In defense of <canvas>

#22

Post by twistedpair »

leeoniya wrote: post #6

re: canvas stacking, check out http://kineticjs.com/

Funny how few canvas libs use stacking of interaction layers. Obviously the slowest part is redrawing quickly for a drag/hover operation. Only one charting example that I know of (CytoscapeWeb) drops the interaction elements to an otherwise empty canvas for the interaction to minimize the redraws needed, and then brings them back when done.

Most just seem to render everything, all the time, in the same canvas element and pray that browsers keep getting more optimized. Funny.

Re: In defense of <canvas>

#23

Post by Adirael »

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…

Will you release an ebook? It seems interesting and I would pay paperback price for an ebook with no DRM.

I got a lot of technical books and they're a PITA to read and store as they are usually pretty big.

EDIT: Went back to the Amazon link and "Paperback: 700 pages", woah.

Re: In defense of <canvas>

#24

Post by kevingadd »

CamperBob2 wrote: post #16
kevingadd wrote: post #9

Earlier quoted context omitted.

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.

I've never actually found a canvas library that delivers consistently better performance, but it is possible. It's difficult because many of the canvas tradeoffs depend on your specific use-case so it's hard for a general library to deliver the best performance. (This is something that is particularly bad about Canvas when compared with other rendering APIs; the way it is specified and implemented makes it harder to work around the performance limitations)

In particular many perf workarounds rely on aggressive caching, and unless you know the workload well it is difficult to create a general-purpose cache that will deliver wins. This is made worse by most modern browsers' particularly low resource ceilings (and in the case of IE, an outright limit on how many canvases you can have)

Re: In defense of <canvas>

#25

Post by exDM69 »

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…

> 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.

Funny that you mention it, the canvas drawing api seems to be inspired by the QBasic-style drawing apis of the 1980s. Unfortunately, computers have moved on since then and these days we have dedicated silicon for drawing and the "immediate mode" way of drawing things became obsolete.

> 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.)

This is not fast. A typical smartphone these days can do thousands of textured 3d models at 60 fps. Hundreds of sprites is next to nothing on modern standards.

It seems like was designed for simplicity, to make it really easy to a few draw lines, boxes and ellipses at the cost of performance.

Re: In defense of <canvas>

#26

Post by simonsarris »

Adirael wrote: post #23
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…

Will you release an ebook? It seems interesting and I would pay paperback price for an ebook with no DRM. I got a lot of technical books and they're a PITA to read and store as they are usually pretty big. EDIT: Went back to the Amazon link and "Paperback: 700 pages", woah.

It's up to the publisher to do that, I know that there will be a kindle edition, but am not certain of any other formats. I imagine all of them will be DRM'd, sorry.

In the near future I will also have a performance chapter in a different book (written quite differently, and expecting more JS knowledge), but that title hasn't been announced yet. That text will have a DRM-free ebook for it, but you'll have to wait a lot longer.

Lastly I'll have learncanvas.com up at some point this summer, where I will begin posting a lot of canvas performance tips with live examples, among other things.

(The page count surprised me too. This is my first book, and it's been quite the overwhelming experience!)

Re: In defense of <canvas>

#28

Post by omerhj »

simonsarris wrote: post #26
Adirael wrote: post #23

Earlier quoted context omitted.

Will you release an ebook? It seems interesting and I would pay paperback price for an ebook with no DRM. I got a lot of technical books and they're a PITA to read and store as they are usually pretty big. EDIT: Went back to the Amazon link and "Paperback: 700 pages", woah.

It's up to the publisher to do that, I know that there will be a kindle edition, but am not certain of any other formats. I imagine all of them will be DRM'd, sorry. In the near future I will also have a performance chapter in a different book (written quite differently, and expecting more JS knowledge), but that title hasn't been announced yet. That text will have a DRM-free ebook for it, but you'll have to wait a l…

http://www.informit.com/store/html5-unleashed-9780672336270

Informit sells PDF, mobi and epub versions of all Pearson books. They print "From the library of Your Name" as a footer on every page but there's no additional copy protection as far as I know.

Re: In defense of <canvas>

#29

Post by davisml »

A few years ago, my friend Austin Sarner and I were writing a user friendly content publishing system in Objective-J. We designed a majority of the controls and UI components using canvas and found it incredibly fast when the proper caching techniques were used.

One of the components of the application I worked on was a text editor that resembled Apple's Pages software. The text editor was implemented entirely in canvas and would wrap live in response objects intersecting the text. Redrawing the text live was slow but we ended up finding a solution. We cached bitmaps of the characters, lines and paragraphs and only re-rendered areas of the canvas that changed.

The code was open sourced and put on GitHub, if anyone is interested:

https://github.com/austinsarner/Frappuccino/tree/master/Frap...

P.S. There's also a really fast iPhoto-style media browser in the repository that is implemented in canvas. It uses image caching techniques for animation.

Re: In defense of <canvas>

#30

Post by plutr »

euroclydon wrote: post #17
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.

The browser already has a scene graph library, it's called the DOM.
Post reply on HN