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

Re: [Public WebGL] Generic compression formats (and a texImage2D API issue)

On Mon, May 10, 2010 at 11:31 AM, Cedric Vivier <cedricv@neonux.com> wrote:
> Hey,
> On the subject of bandwidth and memory savings discussed in the FP16
> thread, I've been wondering for a while if there is
> any plan for a format-independent texture compression hinting
> mechanism (ala ARB_texture_compression) in WebGL ?
> This would bring quite significant performance benefits for a large
> number of use cases since most apps can compress at least a few
> textures, and this would require minimum work for web developers
> (who'd just have to hint which textures are eligible for a given kind
> of compression).
> Using a simplified version of ARB_texture_compression, we could have
> something like :
> gl.texImage2D(gl.TEXTURE_2D, 0, gl.COMPRESSED_RGB, anImage);
> Meaning the image will be stored in a compressed RGB format supported
> by the WebGL implementation and/or driver,
> otherwise an uncompressed internal format is used as usual.
> The mechanism works well within the interoperability constraints of WebGL :
> Generic compressed internal formats are
>    not actual image formats, but are instead mapped into one of the specific
>    compressed formats provided by the GL (or to an uncompressed base internal
>    format if no appropriate compressed format is available).  Generic
>    compressed internal formats allow applications to use texture compression
>    without needing to code to any particular compression algorithm.  Generic
>    compressed formats allow the use of texture compression across a wide
>    range of platforms with differing compression algorithms and also allow
>    future GL implementations to substitute improved compression methods
>    transparently.
> (excerpt from ARB_texture_compression)
> Most desktop WebGL implementations could use ARB_texture_compression
> as-is; on ES 2.0, where the largest benefits could be felt
> (bandwidth-constrained devices), a WebGL implementation could use
> uncompressed data (as it does now) or compress the data to one of the
> supported specific formats (e.g PVRTC) before the actual GL call as it
> see fits (may be too expensive to do on slower embedded CPUs but
> probably not the case on the current 1ghz+ crop, needs perf data).

The topic of texture compression has been discussed in the working
group. The current Web APIs do not provide an efficient way to
download such compressed texture data. For this reason, we resolved to
defer the introduction of compressed textures to a future, post-1.0,
version of the WebGL specification.

> Regardless texture compression, this made me notice an issue with the
> current texImage2D helper signatures
> (having a HTMLImageElement, HTMLCanvasElement or HTMLVideoElement parameter) :
> they do not have a (internal) format parameter, moreover potential
> usage for compression (and/or extensions), it can be useful to
> have such anyways as it would allow, for instance, to load only the
> alpha channel from a PNG into an alpha mask texture,
> without having to perform per-pixel processing in JavaScript using an
> intermediate canvas etc.

This has come up on this mailing list recently and was discussed at
length. Please search the archives for the thread "Retrieving number
of texture channels". At this point this is a request for enhancement.


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

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