[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 6:48 PM, Cedric Vivier <cedricv@neonux.com> wrote:
> Hi Kenneth,
> On Tue, May 11, 2010 at 07:01, Kenneth Russell <kbr@google.com> wrote:
>> 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.
> Hmm, contrary to specific-format compression, format-independent
> compression hinting (like ARB_TEXTURE_COMPRESSION)
> is about NOT requiring web developers to provide textures in one or,
> worse but realistic for interoperability, multiple compressed formats;
> this is about letting implementations or drivers compress image data
> to the best locally available format at texture upload whenever the
> developer has hinted that one texture is eligible for compression
> (generally, a texture with low-detail and/or compression artifacts are
> tolerated).

OpenGL ES 2.0 does not support conversions between the source data
format and the internal format of the texture. This is one of the
subtle differences between OpenGL ES 2.0 and desktop OpenGL. I assume
the reason for this divergence was to reduce the amount of CPU work
done on small devices. For this reason I don't think that compressing
textures on the fly is likely to be supported on OpenGL ES 2.0
devices. All of the texture compression extensions currently in OpenGL
ES 2.0 require the texture to be compressed offline and
glCompressedTex{Sub}Image2D to be called.


> As such, there is no need for Web APIs to download any compressed
> texture data over the network, PNG/JPEG should be sufficiently compact
> for this
> purpose, it is only about storing textures efficiently in video memory
> (and the associated performance benefits).
> I agree that might be better discussed as a post-1.0 feature - though
> a hint does not require full support on every implementation early on
> -
> but we should make sure that it can be introduced later without
> introducing source-level incompatibilities (the lack of internalformat
> parameter
> in commonly used texImage2D helpers unfortunately guarantees that).
>>> 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.
> Thanks for the reminder, I didn't have this thread in mind.
> After reading it again, I think Chris also supported that
> internalformat parameter should be added to tex2Image2D helpers.
> Even if we do not support "conversion" initially (e.g use only
> alpha-channel from a PNG), it deserves a higher priority
> than RFE imho since not having the parameter in 1.0 will introduce
> source-level incompatibilities later and also limit potential
> extensions doing specific compression and/or conversions.
> 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: