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