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

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


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

(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).

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.

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: