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

Re: [Public WebGL] Adding internalformat param to all texImage2d variants



On Tue, May 18, 2010 at 15:10, Mark Callow <callow_mark@hicorp.co.jp> wrote:
> On 2010/05/17 16:10, Cedric Vivier wrote:
>> On Mon, May 17, 2010 at 20:55, Mark Callow <callow_mark@hicorp.co.jp> wrote:
> The parameter you are specifying is the internal format so gl.NONE
> doesn't make logical sense to me. If people really don't want to create
> a new token, gl.DONT_CARE makes more logical sense as a way of telling
> the implementation to select the most appropriate format. However a new
> token gl.SOURCE_FORMAT_WEBGL is much more clear and has the added
> advantage of making it clear that this parameter value cannot be used in
> standard GL.

"NONE internal format is specified." vs "DONT_CARE internal format is
specified." vs "internal format is NONE." vs "internal format is
DONT_CARE".

I don't think one is significantly more legible than the other without
more context.
The context lies in the spec/documentation, something like "If no
internal format is specified (0 or NONE), the implementation will
choose the most compact internal format to represent passed DOM
element without loss of information, according to table X." would be
simple enough I think.


Both DONT_CARE and SOURCE_FORMAT_WEBGL have the disadvantage of being
more verbose and not equal to 0 (a common default in APIs).
Convenience and terseness are important here imo because the more
verbose the less likely that web developers will use this default
instead of just hard-coding say RGB or RGBA, this could make WebGL
content less efficient in general [1].

Making clear that default value is not usable in standard GL is a good
idea but not really relevant here since discussed texImage2D DOM
helpers are obviously WebGL-specific anyways.

I agree with Chris that WebGL should not handle conversion [2] on the
standard texImage2D signature, developers using this
'advanced'/compatibility signature somehow loaded raw pixel data in
JavaScript already, so it better get the most appropriate format
directly from whatever non-DOM source it gets the raw data from (e.g
pre-computed JSON).


Regards,


[1] : e.g 1) Developer hardcodes RGBA, the texture image is later
changed to one without alpha-channel by designer. 2) Third-party
textures that the developer do not control... 3) Existing content
would not be able to automatically benefit whenever a WebGL
implementation support some kind of optimization in the future (e.g
using a lossless compression format if available on the platform the
content runs on).

[2] : some implementations may not perform conversion at all : when an
image is loaded offscreen (e.g via "new Image(url)"), decompression
could happen lazily when the WebGLRenderingContext requests the
HTMLImageElement RGB data, since the image is offscreen it may not
have been decompressed right after download thus only the
color-channel would need to be decompressed from a RGBA PNG, saving
processing time and memory on embedded devices.
-----------------------------------------------------------
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: