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

Benoit Jacob [email protected]
Thu Apr 26 05:36:24 PDT 2012

----- Original Message -----

> 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.
For what it's worth, I'm no longer shooting for a position that I can be 100% comfortable with. For example, in the MRT debate, I amn't 100% comfortable with either the "reject MRT for now" or "accept MRT" options. I see this as a compromise between conflicting goals. 

So the question is rather: how conservative/progressive do we want to be in WebGL, i.e. at what rate should we accept such new features. 

I think that an important criterion to decide that, is: is WebGL really the limiting factor for a given use case? It has sometimes been said on this list that WebGL is currently missing certain features to be able to really compete with desktop games, for certain advanced rendering techniques. My object to that would be that even if WebGL had all these features and then some, we /still/ wouldn't immediately become able to compete with desktop games because there are many other limiting factors at the moment, both in Web APIs and in their implementations in browsers, that make it currently hard for the Web to compete with desktop applications. 

Here is a Mozilla-centric page tracking this as far as Firefox is concerned: 

As you can see, while much of that is Firefox-specific issues, other parts are missing Web APIs and even missing elements in the JS language. 

This is also how we're determining, at Mozilla, what to prioritize as far as game-oriented tech is concerned. If we really thought that OES_foo_bar was the most important thing to implement to help games, we'd prioritize it. (By the way, the s3tc extension implementation bug has a patch as of today ;-) ) For now though, we have finite (even, limited) resources so Web-based games are better served if we focus on the immediate worst problems. 

Of course, other people / vendors can and will still propose new WebGL features/extensions, and we obviously won't oppose them just on the basis that we think we have enough on our plate already (don't want to hold WebGL back) but that explains at least why personally I've not been strongly in favor of new WebGL features for now, except for those that were the most insistently asked for by game developers (anisotropic filtering, compressed textures). 

One way to break my "we have finite resources" claim, though, is by contributing patches, as you did for anisotropic filtering ;-) 
mentored bugs: http://www.joshmatthews.net/bugsahoy/ 
WebGL bugs: https://wiki.mozilla.org/Platform/GFX/WebGL/Resources#Bug_tracking 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120426/1836bd09/attachment.html>

More information about the public_webgl mailing list