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

Re: [Public WebGL] ETC texture compression.

On Wed, Aug 25, 2010 at 01:13, Chris Marrin <cmarrin@apple.com> wrote:
The bottom line is that a WebGL implementation supporting ETC1 would have to accept these textures as input, what it does with them is implementation specific. But for universal support an unencumbered ETC1 decompressor is needed.

Not if we limit ourselves just to provide access to low-level ES 2.0's compressedTex* functions.
I still do not understand the fears of incompatibilities it generates as using it is essentially exactly the same mechanism than for using any extension (ie. may not be available so developer has to be careful about it - ie. getExtension("SOME_FORMAT") doesn't give the format enum).

Providing access to compressedTex* functions makes compressed formats completely transparent to the WebGL implementations, developers just provide the functions with an UnsignedByteArray obtained elsewhere (eg. XMLHTTPRequest), therefore not requiring unencumbered decompressors and the likes.

Libraries and/or web services can provide high level wrappers for easy developer usage and interop guarantees.

Last but not least, there's no technical advantage in space or time at all at using ETC1 (or any decompression-optimized GPU-supported format) over the wire when it needs to be decompressed in software because hardware does not support it.