I guess I'm just trying to understand why Abobe went the route of turning DOM elements into 3D rendering contexts, instead of just giving developers a way to get textures from DOM elements, and decide how to use those textures themselves. The latter would be much more useful in my mind (and yes I've written a lot in WebGL). Adobe's approach doesn't stop any cross domain security issues either, and it just limits the flexibility the animations programmer has.
It makes me suspicious that Adobe is just trying to get something that they see as useful for themselves incorporated into Webkit, even though it doesn't fit the WebGL work flow.
Well, this would certainly fit my workflow. Because I'm not a 3D-programmer and this approach is a much better fit for the casual 2D-games I want to make.
I guess I can come around to how this might be useful for some effects. I don't necessarily think it would be useful for 2D games though, as there's a lot going on there so you might be better off to just do a 2D-canvas based game.
Just off the top of my head: cheap glow effect, ripple effect (e.g. when a bomb goes off), post-processing filters for things like film effects, etc. You don't need to be doing 3d work to make great use of shaders.
"instead of just giving developers a way to get textures from DOM elements"
I'm guessing this functionality is already in progress. Canvas has a bunch of draw operations on it and browser makers are already extending it with functions like drawWindow(). I'm guessing it won't be long before we see a Canvas.drawDOM() method
No, there are too many security problems. You could do history sniffing with drawWindow(), for example, by making a link and checking the color. Or you could read the contents of cross-domain iframes, allowing web pages to discover your Facebook identity.
It does help cross domain security issues a bit. Without WebGL's readPixels the only possible information leak is a timing attack, which is much less practical.
The security considerations of allowing web content to load arbitrary compiled shaders onto the GPU are important. This of course also applies to ordinary WebGL.
While the ability to write your own shaders is awesome, I'm actually most excited about the built-in options. The ability to add a non-crappy (read: not a simple box) dropshadow with one line of CSS makes me jump for joy.
If they pull this off it'll remove one of my biggest sore points from transitioning from Flash. Flash had these filters, and they were incredibly useful (color transform, glow, blur, and dropshadow especially).
13 comments
[ 1.9 ms ] story [ 44.2 ms ] threadIt makes me suspicious that Adobe is just trying to get something that they see as useful for themselves incorporated into Webkit, even though it doesn't fit the WebGL work flow.
I'm guessing this functionality is already in progress. Canvas has a bunch of draw operations on it and browser makers are already extending it with functions like drawWindow(). I'm guessing it won't be long before we see a Canvas.drawDOM() method
Firefox has supported it as an extension for a while now but it's not enabled for content due to the security problems.
Adobe addresses the topic briefly in their W3C proposal: https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#s...
I wonder how the shaders will be vetted in practice?
If they pull this off it'll remove one of my biggest sore points from transitioning from Flash. Flash had these filters, and they were incredibly useful (color transform, glow, blur, and dropshadow especially).