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

Florian Bösch [email protected]
Thu Apr 26 06:02:10 PDT 2012


On Thu, Apr 26, 2012 at 2:36 PM, Benoit Jacob <[email protected]> wrote:

> 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:
>   https://wiki.mozilla.org/Platform/AreWeFunYet
>
> 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
>

I understand the "best use of our resources" argument, and those sites and
bugs and features which are more pressing to do are all good, and I
wouldn't want to prioritize experimental graphics extensions over that, by
no means.

But we still have the chicken&egg problem. Extensions get rejected because
their mobile (or even desktop) support is lousy or they are deemed non
essential by seasoned folks. I agree with the assessment, most of these
advanced things are not well supported and they might not turn out to be
popular or essential. But the problem is that professional opinions aside,
if an extension does not make it to a publicly released build (not a
developer build), we can't answer either the question of support level nor
the question of developer popularity with any significant statistical
certainty.

For example, I could tell you how well compressed textures and anisotropic
filtering is supported on http://webglstats.com/, but I can't, because it
has not been released to public builds. I just have a couple dozen
impressions from developers with dev builds. Unless you actually release
it, you won't get any useful information out of http://webglstats.com/ for
that question. Now, I understand anisotropic filtering hasn't been released
because we wait for an angle Direct3D fix. Texture compression has not been
released for reasons I don't know (was it the wait for WebGL 1.0.1?). On
any account, it takes a long while and those are at least extensions that
made it to WebGL draft.

Now say something like MRTs, that never make it even to draft, it will
never see a released public build in any form or shape. But, if you don't
release it somehow, you will never get a good answer if web-3d developers
like it, and how well it's supported by the web audience. This makes me
miserable, because it gives me the feeling we're frozen in time, and we
can't try to get cutting edge features to WebGL for a long, long time.

I'd like us to resolve this somehow so we can get cutting edge features,
without sacrificing lowest common denominator benefits. It'd like all of us
to have our cake and eat it too, and I believe it can be done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20120426/432c99c1/attachment.html>


More information about the public_webgl mailing list