Learning WebGL
learningwebgl.com
learningwebgl.com
For example, let's say you have 150MB of art assets. You wouldn't want players to have to re-download the assets each time they go to play.
So how would you cache: 1) a texture, 2) a vertex+index buffer?
Alternatively, if you want to have a more install-like install, you might have luck with local storage: http://diveintohtml5.org/storage.html
Local storage seems to currently max out at 5 MB, but that's easy for the browser vendors to change if they see the need.
What we need is a way for a site to say "i'm an app" which will tell the browser to store the cache in a separate bucket. Then when users go to clear their cache, there is a separate checkbox for web apps which is uncheck by default (just how passwords are unchecked by default).
This is what Mozilla should be working on with it's web apps project. The installation part is just mascara. We need the browsers to do the distinguishing, not users.
Localstorage is useful, but as you say limited.
The real solution is IndexedDB. Partial (but useful already) support is in Firefox and Chrome. Other browsers are expected to follow soon.
And as if that wasn't enough, browsers don't trust expiration dates in HTTP, either. Press reload enough times, and all resources will be reloaded.
One issue with WebCL is the device support. WebGL is capable of running of pretty much anything but WebCL (unless they decide to make a fake software version for system who don't support it in hardware) is going to be limited to a small subset of clients for a while.
I don't know if you've noticed, but most WebGL users are on personal computers and not mobile devices. The only mobile implementation I've seen is FF4Mobile and it's quite inadequate for all but the simplest WebGL programs. Most PC GPUs have had floating point readback for a few years now. Additionally, the irony of the situation is that ALL of JS numbers are doubles and ALL OpenGL ES 2 GPUs use floating point internally. It is really only the standards that have not caught up and force devs to do int-float conversion across the GPU boundary. Add to this the performance constraints of 3d rendering and any sane dev will want to do as little in JS and as much in GLSL (on GPU) as possible.
I asked Kenneth Russell, the Chrome WebGL lead, about floating point readback support at GDC and I was told that I'd "just have to do the pee-pee dance".
With this single capability, many tasks "needing" WebCL become possible with WebGL. OES_texture_float (according to WG members) only allows loading float textures, not reading out of them.
I wonder if Adobe and Microsoft know to use floating point for GPU computing? Here's hoping that a little competition fixes this blatant oversight.
This is after all version 1.0 of the standard. I don't see why 1.1 can't include optional support for OES_texture_float.
Does the iPad support it? I know a lot of android phones do too. So no reason it should be barred.
OES_texture_float is a current WebGL extension that is implemented by several browsers. The issue is that OES_texture_float does not specify readPixels support. As far as I can tell, even with native OpenGL ES 2, there is no extension that specifies readPixels functionality for floating point textures. I believe this is a bug in the OES_texture_float specification as binding a texture format to a texture engine is entirely type-level and no types are required after the resource is bound. If there is a hardware limitation, you're doing it wrong.
So the current state of support is: some browsers implement OES_texture_float and you can load floating point textures. Some browsers, when you have enabled OES_texture_float, also allow writing floating point textures. Unfortunately, the only thing you can do with a written floating point texture is re-read it in a later vertex (if you can get vertex texture fetch support which is still lacking for WebGL on Windows due to DirectX impedance mismatch) or fragment shader.
If you want to read back the results of your float computations, you have to pack them into 4 x 1 byte pixel color channels and then unpack them on the javascript side back into floats. Of course, when converting the GPU native floating point values into color channel integers, implementations "helpfully" clamp to [0..1] and then multiply by 255 (!) so that 0 -> 0 and 1 -> 255. This plays havoc with floating point precision as 255 is not exactly representable. Complicating matters further, ES2 and its corresponding GLSL have no provision for integer or bitwise operations and so the implementor is reduced to using floating point operations to pack floating point values into 4 [0..1]-values that then get molested into 4 byte arrays which can then be read back into Javascript which can then waste browser/CPU time rebuilding floating point values from pixel byte channels with accompanying (technologically unnecessary) numeric noise.
I've not seen any WebGL implementation running on the iPad and Apple won't say anything about it. If I had to guess, I'd say that WebGL is attractive to Apple in the HTML5 sense but not in protecting their native application advantage. The Steve will probably decree that native 3d apps have superior performance by virtue of not being written in a sloppy, GC'ed language and run in a giant sandbox. I don't think native iOS apps allow float texture read-back, either.
The real question is: Is WebGL's lowest-common denominator (phones) approach to 3d a bug or a feature? On the bug side, it's absurd that I can't read float values off of my desktop GPU in 2011. On the feature side, it means that even your iPhone 3G will be able to poorly execute and render a WebGL application at an unbearably low framerate!
Our stats indicate the IE is much less of a problem than expected.
On the other hand, have you looked into modern UI architectures? Particularly on mobiles, they look a lot like operating systems aspiring to be web sites...
MS is using this trick with Hotmail: You need IE version X to benefit from the amazing features hotmail has.
Even though the spec has hit 1.0, the dust hasn't nearly settled on the implementations. Lots of demos only work on specific browsers or have been broken by browser updates. Meanwhile, MS is apparently extremely devoted to not breaking sites that used to work when they put out new updates. I'm personally OK with MS waiting until WebGL solidifies before putting out their first implementation (hopefully...).
I think if the games and toys are enough fun, people won't care that they have to run it in a different browser. Hell look at how many people buy new computers just to run the latest games.
3D on the web in my mind will be most useful for games and I believe scientific visualization and engineering applications which are usually people who don't care about installing a different browsers.