[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Generic compression formats (and a texImage2D API issue)
On May 10, 2010, at 6:48 PM, Cedric Vivier wrote:
> Hi Kenneth,
> On Tue, May 11, 2010 at 07:01, Kenneth Russell <email@example.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
> 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
> in commonly used texImage2D helpers unfortunately guarantees that).
I've thought about this as well. We could support a compressed texture format without actually defining any specific formats. Doing it as a hint, the implementation would be free to ignore it and store the texture uncompressed, or use whatever texture compression format is available in the driver. This avoids the licensing issues associated with texture compression. If your implementation has rights to a compressor that is used in your graphics driver, then you can implement it.
My only concern about this is that different texture compression formats have different rendering characteristics. Some have more green resolution than blue, others have more luminance resouiton that chrominance, etc. This could cause inconsistencies. But as long as the author understands that using compression is always an approximation, I don't think this problem is too significant.
But I also think this should go on the list for post 1.0.
You are currently subscribe to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: