[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




On Thu, Apr 26, 2012 at 2:36 PM, Benoit Jacob <bjacob@mozilla.com> 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.