Live data from Hacker News

HTML 5 canvas graphics library

exsprite.com

11–19 of 19 posts

Re: HTML 5 canvas graphics library

#11

I'm always glad to see more canvas libraries, but the performance of this one is pretty horrendous. I'm writing a comprehensive canvas diagramming library that is now up to 70K lines and its no where near this slow. In case the author reads these comments I'll mention a few I see at first glance: They are doing things like setting the font every on single draw unnecessarily (which takes a surprising amount of time, p…

I agree, I watched the demos and thought it had horrible performance. Did you say your library had 70K lines!?!!?

Yes, but there's an awful lot of stuff that needs to run once at the start (premade geometric figures and the like). Once compressed of course it is much smaller.

Re: HTML 5 canvas graphics library

#13

I'm always glad to see more canvas libraries, but the performance of this one is pretty horrendous. I'm writing a comprehensive canvas diagramming library that is now up to 70K lines and its no where near this slow. In case the author reads these comments I'll mention a few I see at first glance: They are doing things like setting the font every on single draw unnecessarily (which takes a surprising amount of time, p…

I'm also kind of sick of seeing stuff done with canvases that could probably be done as efficiently or more efficiently without. (It would be particularly cool for someone to implement a library that abstracted out the back-end, so you could run in DHTML4 or excanvas or a real canvas.)

limejs does that, but it uses google closure

Re: HTML 5 canvas graphics library

#14

How does the performance of this compare to other libraries like PaperJS ( http://paperjs.org ) or EaselJS ( http://easeljs.com ) or ProcessingJS ( http://processingjs.org/ though I understand Processing doesn't really have a display list)?

From my experience EaselJS is pretty fast. You gotta be aware of the demos on Firefox, because it gets pretty slow due to multipe error messages unless you set the following flag:

    DisplayObject.suppressCrossDomainErrors = true

Re: HTML 5 canvas graphics library

#15
This is great, it's similar to Flash's display list. I actually think a display list should be part of the canvas spec. There's really no reason to have a bunch of competing display list libs and it could be optimized if it was part of the browser.

Re: HTML 5 canvas graphics library

#17
Okay. I wrote StrikeDisplay.blogspot.com which does what this is trying to do. I haven't had much time to work on it for awhile, but I try to keep an eye on developments in this area.

I reviewed the code. I think it's a good effort and it's on the right track, as far as developing a seamless parent/child display chain coupled with event chain for the kind of things we take for granted in Flash. It gets some things right; like apparently re-scoping mouse events with target and currentTarget, which is good if you're expecting methods listening for the events to be scoped in some other way than window or document.

The two issues I see with this library are serious deficiencies in performance -- which could be improved upon, of course, although some of the architecture requiring redraws on every frame is just inefficient as has been pointed out -- and also issues with the way bounding boxes are implemented and how collision/rollover checks are implemented. First of all, it useless to have rollovers always based on rectangles, especially if there aren't careful z-ordering methods. Secondly, having an inner and outer bounding box is a very slow method for traversing the redraws and checking events (so are a lot of other bb methods in canvas. everything's slower in canvas than in Flash). The closer to native browser bone you can cut on this, the better; my solution to click collision checks in StrikeDisplay was to implement a hidden canvas on top of the visible one, that duplicated everything drawn in white, everything else in black, and check the pixel color value of that canvas when the mouse clicked or went over anything inside a bounding box. This turned out to be a hell of a lot faster.

I'm happy to see these kinds of libs come out, because if we do have to give up all the comforts of flash or unity or javafx to develop in this nightmare DOM with nothing but a raw canvas, the sooner we can bridge the gap between visual-oriented coders and everyone else, the better for everybody. This one needs work, but I'd rather see something along these lines than most of the other stuff I've seen come out that's DOM-centric rather than based on a display chain.

Re: HTML 5 canvas graphics library

#19
post #13

Earlier quoted context omitted.

I'm also kind of sick of seeing stuff done with canvases that could probably be done as efficiently or more efficiently without. (It would be particularly cool for someone to implement a library that abstracted out the back-end, so you could run in DHTML4 or excanvas or a real canvas.)

limejs does that, but it uses google closure

I've seriously thought about surgically removing Closure from limejs. It uses a lot of Closure classes (i.e. Vector2) so it wouldn't be clean, but improving the build process would be worth it.
Post reply on HN