It's a shame that so much effort is put into an HTML5 page that is obviously trying to demonstrate the frameworks it is promoting and yet get the experience so awfully wrong on a touch screen device like the iPad.
You're right that a framework that should provide mobile compatible animations should have a website that is itself mobile-friendly.
However the page itself doesn't seem to use any of the frameworks it is promoting, and doesn't seem to do a lot of demonstrating as of yet. The full site is apparently coming soon though...
It sucks on a desktop machine too. You have to hover each icon to make a slowly in-fading low-contrast (and apparently a colourful mess due to not being a good font for my monitor) vague one line description appear.
Actually this is a framework that is being integrated into the current line-up of Adobe Flash IDE to convert/export your Flash SWF animations to HTML5 canvas. I believe this has tremendous potential, since there aren't many/any IDE's available to create animations for the Web using HTML5. I suggest you to kindly check this link out:
Ah I see, I was tremendously confused by the site. The site itself does not actually explain any of this, and I am not a user who actively follows this stuff. So when I clicked on the site I saw a bunch of frameworks, with no understanding of how they were linked, or what their purpose was. I hope you can see how I was confused. And the title of the HN post does not link to what the actual purpose of the frameworks is, i.e. a set of tools for flash exporting to html. I felt like the site did not provide any of this context. That explains a lot. Thanks.
the big mistake they are all doing is to work directly on the canvas instead of just taking a canvas as input and deliver another canvas as output (optional async to a callback).
said that, i'm currently working on a solution, a simple functional canvas lib, one canvas goes in, another canvas comes out. no side effects.
the simple answer is: because simple is better than complicated
...
var blurFilter = new BoxBlurFilter(32, 2, 2);
var margins = blurFilter.getBounds();
bmp = bmp.clone();
bmp.filters = [blurFilter];
// filters are only displayed when the display object is cached
// later, you can call updateCache() to update changes to your filters
bmp.cache(margins.x,margins.y,img.width+margins.width,img.height+margins.height);
bmp.x += bmp.x+img.width;
stage.addChild(bmp);
...
should be
var blurcanvas = boxBlurFilter(originalcanvas,32,2,2);
and then, if we want to see it on the page (i.e. instead of the original canvas)
$(originalcanvas).replaceWith(blurcanvas) //or any other jQuery mumbo jumbo
The problem is that canvas are not cheap enough. And there are numerous scenarios where wasting them will prove to be a huge disadvantage to performance. Which is already mostly a problem in JavaScript, and the web in general.
for web-sized-pics and (instagram like) filter-effects (even effects stacked upon each other) they are cheap enough, but yeah, that question will only be solved with real world performance tests.
from my point of view: most of the canvas (effect) libs smell like premature optimization to me. could be wrong, though.
The context is within an thread on Animation. Yes, of course it's cheap enough for an effect you are just generating a still of, but it is a measurably slow approach for anything that needs animation.
And couldn't you create the kind of library you wanted by simply making a wrapper that called did something like
function X(canvas, ...) { var C = canvas.clone(); oldX(C, ...); return canvas }
You can't really do the opposite and get the performance advantages.
In StrikeDisplay, vectors and images are held as Sprite objects in the AS3 sense - which are represented as draw lists internally, and only drawn/redrawn to the canvas as necessary. When a filter requiring convolution or blurring is applied to one of these Sprites, a unique canvas is generated for that individual Sprite+Filter, which is substituted for the original draw list (temporarily). Same thing that happens if you just cache the sprite as a bitmap. So the procedure in StrikeDisplay to draw a black box, add it to the stage and put a blur and a dropshadow on it is:
var s:Sprite = new Sprite();
s.graphics.beginFill("#000000",1);
s.graphics.drawRect(0,0,100,100);
root.stage.addChild(s);
s.filters = [new BlurFilter(4), new DropShadowFilter(2,2,4,"#000000",.8)]
And that's it. It's now automatically drawn to a hidden canvas, which becomes the only item on the Sprite's draw list, retaining the position and transform properties, parent and event hierarchy of the original Sprite. If you modify the Sprite later, re-filtering and re-caching happens automatically. And if you remove the filters, the original vector draw list is restored and the hidden canvas that fed the filtered version is emptied and deleted.
On a related note, gskinner is also responsible for one of the coolest regex tools: http://gskinner.com/RegExr/
It's written in Flex and is also available as an Air app, makes writing regular expressions almost intuitive.
It's a shame that so much effort is put into an HTML5 page that is obviously trying to demonstrate the frameworks it is promoting and yet get the experience so awfully wrong on a touch screen device like the iPad.