[Public WebGL] Advanced features and the chicken/egg problem

Florian Bösch [email protected]
Thu Apr 26 04:08:55 PDT 2012


Let me quickly recap our discussions we had so far about features that
don't run on mobiles.

A: "Can we have X"?
B: "No, it doesn't run on mobiles."
A: "But it's cool"
B: "We don't know how well received it would be by developers, let's just
wait and see"

See what? Wait for when? Will it ever run on mobiles? When will it run on
mobiles? and so forth.

The two primary clashing interests in this discussion are these:
Camp conservatives: Appeal to the lowest common denominator of hardware to
get WebGL to as many people as possible (angry birds, tic-tac-toe,
3d-tetris, spinning cubes, etc.)
Camp progressives: Use advanced capabilities to make something awesome and
accept that only a minority of users will be able to enjoy it (battlefield
3, crysis 3, productivity software, graphics research, realtime terrain
errosion, etc.)

We can't resolve this debate on top of WebGL because the "wait and see"
approach is extremely slow and possibly does not terminate. In some
circumstances you will never "see" because unless you introduce a feature,
you don't know how well supported it is, or how popular it turns out to be.
But the position of the conservative camp that we shouldn't introduce
fragmentary features on WebGL which is intended for the lowest common
denominator has validity.

So since I don't see how we could resolve this debate in finite time with
WebGL, and I'm less than enthused about waiting for things (I'm impatient,
I know), I think this calls for a new strategy to deal with the issue.

I'm just going to throw it out there, can we introduce some kind of API
that we can use, that would be quite similar to WebGL, but would allow us
to use all the "good bits" as well? For instance something like:

var ctx = canvas.getContext('webgl-and-all-the-good-bits');

The "all the good bits" contexts would have their own extensions that you
can't obtain in vanilla webgl. All the good bits contexts would be way more
experimental and would ratify extensions quicker, and we can use it as a
testbed to measure up support for features as well as developer enthusiasm
for them.

I've written http://webglstats.com/ so we can get a good overview of the
ecosystem and have a tool at our hands to help us in decisions towards
functionality, and to ensure users know what they're gonna get into by
relying on some feature. But unless we can actually push ahead new features
faster and more safely, it's not gonna help us evaluating features (it's
just gonna help us evaluating existing functionality).

What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120426/2d17f9c6/attachment.html>


More information about the public_webgl mailing list