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

Re: [Public WebGL] Move flipY and asPremultipliedAlpha parameters out of DOM helpers

On Wed, May 19, 2010 at 7:03 PM, Kenneth Russell <kbr@google.com> wrote:
On Wed, May 19, 2010 at 6:53 PM, Gregg Tavares <gman@google.com> wrote:
> On Wed, May 19, 2010 at 6:45 PM, Kenneth Russell <kbr@google.com> wrote:
>> On Wed, May 19, 2010 at 6:31 PM, Cedric Vivier <cedricv@neonux.com> wrote:
>> > On Thu, May 20, 2010 at 08:52, Kenneth Russell <kbr@google.com> wrote:
>> >> On Wed, May 19, 2010 at 5:38 PM, Cedric Vivier <cedricv@neonux.com>
>> >> wrote:
>> >> Changes to texture parameters take effect immediately. There are no
>> >> texture parameters which affect the behavior of later calls (for example to
>> >> glTexImage2D) but whose changes are not otherwise seen.
>> >
>> > Change to texture parameters *values* take effect immediately yes!
>> > I strongly disagree that there is such a requirement for new values to
>> > be acted upon immediately.
>> >
>> > As a matter of fact I gave GL's GL_GENERATE_MIPMAP texture parameter
>> > as example, which is defined as :
>> >
>> > """
>> > Specifies a boolean value that indicates if all levels of a mipmap
>> > array should be automatically updated when any modification to the
>> > base level mipmap is done. The initial value is GL_FALSE.
>> > """
>> >
>> > It is clear here that this parameter does _not_ take effect
>> > immediately as it generates mipmaps automatically "**when** any
>> > modification to the base level mipmap is done". "Modifications" here
>> > imply tex(Sub)Image2D calls, this texture parameter is indeed a way to
>> > avoid having to call glGenerateMipmaps after every modification.
>> If you call glTexImage2D and later enable the GL_GENERATE_MIPMAP
>> texture parameter for the texture object, then as far as I know, the
>> mipmaps are supposed to be generated immediately, the same way that
>> changing the wrap mode takes effect immediately. OpenGL ES 2.0
>> eliminated the GL_GENERATE_MIPMAP texture parameter, replacing it with
>> the explicit glGenerateMipmap, presumably because of ill defined
>> semantics.
>> This proposal is not workable.
> Are you objecting to the design or specifically to overloading
> texParameteri?
> Assuming the idea is sound we could easily make it texImageParameteri(...)
> or something like that.
> There are plenty of state settings in GL that effect something that happens
> in the subsequent calls and otherwise do nothing. glActiveTexture,
> glBindBuffer, glBindTexture, etc, functionally do nothing but setup state
> for calls made later.

I am objecting to both. First, the overloading of texParameteri has
very poor implications as I've already pointed out. Second, I see no
advantage to changing these two flags to state bits that must be set
before calling texImage2D, and several disadvantages, including making
developers write more code and requiring the WebGL spec to specify new
enums. One might as well make the proposed internal format a
configurable parameter in the WebGL helpers (which I would not

At a minimum I personally think we should be shooting for the OpenGL version (not ES) of texImage2D where source format is separate from destination format and the overloaded helpers are only specifying the source format automatically since they have that info.

Unfortunately, OpenGL ES doesn't have enough format enums to support the internalFormat parameter the way OpenGL does so we're left with a few options

1) Add those emums to WebGL to make texImage2D basically work the same as it does on OpenGL with the conversions.

2) Add an internalType argument to texImage2D so it can separate the source format from destination format without adding new enums.

3) Add state settings for conversion

4) Pick some poor hack that only handles 8bit->8bit conversions.  

5) Do no conversions. Leave it like OpenGL ES 2.0.

What I don't get is why the need for these conversions? If you load a grayscale image as RGB you'll get the same visual result as LUMINANCE. So it seems like the valid reason to do these conversions is for memory savings since you can always create RGB or RGBA textures that will give you the same visual result.

If memory savings is the reason to put in the conversions than we should be converting to ALL valid OpenGL ES standard formats and not just a couple of them.  That suggests that option #4 is out.

Option #3 has the beauty that you can add more and more options over time and not break any function signatures.

ctx.texImageConversionParam(ctx.COMPUTE_GRAYSCALE_WITH_COLOR_BIAS, 1);
ctx.texImageConversionParam(ctx.FLIP_Y, 1);
ctx.texImageConversionParam(ctx.MAP_R_TO_CHANNEL, 3);  // sets are to go to ALPHA channel
ctx.texImageConversionParam(ctx.INTERNAL_TYPE, ctx.UNSIGNED_SHORT_4_4_4_4);

There are tons of image processing libraries that work this way.

But I don't care if we don't go for option #3. I do care that if we add conversions that we be consistent and support them to all the standard formats.