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

Re: [Public WebGL] ETC texture compression.

Cedric Vivier wrote:
> On Wed, Aug 25, 2010 at 08:59, Steve Baker <steve@sjbaker.org
> <mailto:steve@sjbaker.org>> wrote:
>     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. 
> I agree, counter-intuitively I'd think an extension with available on
> only 50% systems to be better supported for everyone (ie. have
> fallbacks) than an extension that runs for almost everyone (90%+) thus
> the developer might be less interested to do the effort.
Maybe - but what tends to happen is that the 50% of hardware that has
the extension is the 50% which are the latest, greatest, fastest GPU's -
and the ones that don't support it are the slowest, oldest, crappiest
ones.  So supporting the extension in your application makes the
machines that are already plenty fast enough to run your app run yet
faster - and leaves the slower machines running the cruddy fallback code
- which is likely to be slower.

Enthusiasm for using such extensions is generally small...especially if
it takes significant art changes to make use of it.

Having said that, the ETC extension isn't like that - it's (presumably)
supported on cellphones but not on desktops - the cellphones are short
of RAM - so they need compression - but most desktops have at least 6x
more video RAM than cellphones do - so perhaps they don't need 6x
compression in order to run the same applications.   That makes it worth
supporting ETC as an extension.
> Also the specific case of compression extensions is the easiest kind
> of extension do fallback for, eg. :
> var format;
> if (format = gl.getExtension("ETC2")) {
>     loadETC2Texture(format, name);
> } else if (format = gl.getExtension("ETC1")) {
>     loadETC1Texture(format, name);
> } else if (format = gl.getExtension("PVRTC")) {
>     loadPVRTCTexture(format, name);
> } else { //fallback
>     loadPNGTexture(name);
> }
Well...kinda.  The trouble is that not all maps 'survive' a particular
compression scheme - often artists and shader programmers have to make a
case-by-case call.  If you need ETC2 to support alpha - then falling
back to ETC1 isn't going to work.   Similarly, we're not going to be
using ETC1 for normal maps - no matter whether it's supported or not.  
If you know that the underlying hardware is going to crunch your
beautiful 8/8/8/8 textures into 4/4/4/4 and your 8/8/8's into 5/6/5 no
matter what - then maybe you don't mind that ETC1 is going to reduce
your color precision...but maybe you figure that now it's only giving
you 3x compression instead of 6x and you might prefer to stick with
uncompressed maps...it's a really tricky decision.

I've been wondering how hard it would be to generate a compression
scheme that ran in shader code using only standard texture facilities. 
Maybe one could emulate ETC1 inside the shader for desktop machines
without ETC support...but without access to texture2DLod and ddx/ddy
functions, it would be tough.  But if we had WebGL generate extra shader
code to do it on hardware that doesn't support ETC1 but does support
texture2DLod/ddx/ddy then maybe we'd end up with universal ETC1 coverage.

Are there any machines that don't support ETC1 AND don't support
texture2DLod/ddx/ddy in the fragment shader?
> That said, I like the concept of a lowest-common denominator WebGL
> that guarantees WebGL code to run anywhere, especially for 1.0, on the
> other hand for the future of WebGL I'm wary of privileging policy
> decisions over technical decisions when it comes to give more power to
> advanced developers (indeed - more power means more responsibilities,
> there's always ways to make an app fail on some platforms)
I understand completely.

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: