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

[Public WebGL] Re: WebGL spec clarifications



On Nov 15, 2010, at 4:46 PM, Ligon, David wrote:

> Hey Chris,
> 
> I am looking at the WebGL spec and have some questions that I cannot find clear answers to.
> 
> I noticed support for compressed texture enums:
> 
>    const GLenum NUM_COMPRESSED_TEXTURE_FORMATS = 0x86A2;
>    const GLenum COMPRESSED_TEXTURE_FORMATS     = 0x86A3;
> 
> But I did not see
> 	void CompressedTexImage2D( enum target, int level,
> 		enum internalformat, sizei width, sizei height,
> 		int border, sizei imageSize, void *data );
> 
> It appears that
>    	void texImage2D(GLenum target, GLint level, GLenum internalformat, 
>             GLsizei width, GLsizei height, GLint border, GLenum format, 
>            	GLenum type, ArrayBufferView pixels);
> 
> is a similar format.
> 
> Is "format" overloaded in WebGL to include compressed formats?  If so, this seem contradictory to the pointer to the spec page being pointed to:
> 
> "void texImage2D(GLenum target, GLint level, GLenum internalformat, GLsizei width, GLsizei height, GLint border, GLenum format, GLenum type, ArrayBufferView pixels) (OpenGL ES 2.0 man page)"
> 
> Perhaps CompressedTexImage2D should also be pointed to....

These are all good comments, Dave. I'm adding the public list to get more comments.

My comment is, yes, this is an inconsistency in the spec. As of now we don't support any compressed texture formats. We have discussed supporting ETC1 (and maybe ETC2?) since it seems like they may be moving in the direction of being IP free. But for now I believe we plan to ship WebGL 1.0 without any specified support for compressed textures. 

There are really a couple of issues here. One is that it is currently not easy to download binary data, so it's difficult to get compressed image data into the system. This is being solved by making it possible to get an ArrayBuffer (our binary data object) back from XMLHttpRequest (HTML's generic data fetching mechanism). The other question is, when we can get binary data in and when we decide on the compressed format(s) to support, what calls do we make? My preference, and I believe the solution we have discussed, is to use the current texImage2D call. As you noticed, it has separate format and internalformat params, which should be sufficient to allow incoming compressed data.

If we do that, do we need the compressed format enums? I don't think we do. I think it would be better to simply mandate support for whatever compressed format we agree on. 

So I think the action item is to remove the compressed texture enums. I think it's clear enough in the texImage2D prose that no compressed formats are supported.

Other comments?

-----
~Chris
cmarrin@apple.com




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