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

Re: [Public WebGL] ETC texture compression.

Vladimir Vukicevic wrote:
> The extensions that we're looking at are things that are defined as extensions, but generally have very wide (or universal) availability.  So that argument doesn't apply there -- it's very different defining an extension for webgl for something that will be present on 95% (if not 100%) of target hardware, vs. something that is known to not be present on half or more.
>     - Vlad
The trouble is that if the extension is "nearly" universal - and useful
enough to matter, many application authors are going to be tempted to
use it - and not bother to write fallbacks for it because the additional
revenue from (say) 5% of the market would not pay for the additional
development cost.  Also, a lot of ground-breaking web sites are produced
by amateurs who may well find themselves unable to dig up a sufficiently
ancient machine to test on to debug all of these possibilities.

If WebGL programs don't run exactly the same everywhere, the web will
become full of apps that simply fail for ill-explained reasons on random
machines.  That will reflect badly on the standard.   I think we should
avoid extensions in at least the first version of WebGL for exactly that

On balance, I would prefer that we didn't ever provide extensions.   I
believe that we should be aggressive about the hardware you need in
order to be able to run WebGL.  If 5% of machines don't have some
important and "nearly" universal extension then let's make that a part
of the core API and declare the 5% of machines obsolete and unable to
support the API.  Let's drive the community rather than lagging it.

Right now - even without extensions - we have problems.  Sometimes the
underlying OpenGL will silently fall back on software emulation to
implement a feature rather than admit that the hardware can't do it -
and the result is too slow to use (Vertex textures...to pick a
particularly nasty example).  The spec claims that you can use this
feature - but in practice it's not always usable - and the only way to
detect that there is a problem and provide a fall-back is to measure
in-game frame rates (which given garbage collection and the general
randomness of timing in a browser environment is tricky at best)...argh!

   -- Steve

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: