

HTML 5 canvas graphics library - djd
http://www.exsprite.com/

======
simonsarris
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, performance-wise). Actually they are
resetting nearly all of the canvas state by hand on each draw, which can just
as easily be done in the much faster way by doing "canvas.width =
canvas.width". But even that they shouldn't do if they can avoid it.

Similarly the author should not set the globalCompositeOperation all the time
unless he or she really needs to.

I'm sure there are a lot of other low-hanging fruit that can be fixed. I'll
try send the author an email later tonight. I hope they keep at it.

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

~~~
jigs_up
limejs does that, but it uses google closure

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

------
shashashasha
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)?

~~~
DanielRibeiro
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

------
mcantelon
I made something similar a ways back (a little rough, but some fun features
like defining sprites using ASCII characters):

<https://github.com/mcantelon/grout>

Here's a game I made with it:

<http://mikecantelon.com/demo/demo_blood_funnel.html>

------
DanielRibeiro
Interesting. But I wonder why I'd use this instead of EaselJS:
<http://easeljs.com/>.

~~~
noduerme
well, Grant's a joker that ripped off plenty of my ideas and code; but it's
not horrible if you have to use somethin.

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

------
Turing_Machine
Cool...other than the parts that need click or keyboard input, all the demos
seem to work, more or less, on my iPhone 4S (Canvas Creatures is pretty
sluggish, though) and Kindle Fire (both Canvas Creatures and Snake are
sluggish there, and Canvas Creatures looks a little weird, like the maybe the
alpha channel isn't quite working. This may be a limitation of the Kindle
display or browser; I haven't had it long enough to judge).

How about adding support for touch events and gestures? :-)

------
AshleysBrain
Something like this with an alternative WebGL renderer would be cool! It can
make it a lot faster - see a blog post I wrote on it:
[http://www.scirra.com/blog/58/html5-2d-gaming-performance-
an...](http://www.scirra.com/blog/58/html5-2d-gaming-performance-analysis)

------
daniel-warner-x
I miss Flash. I know it had big issues but this stuff makes for some hard
livin'.

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

