[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 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 :
>
> """
> GL_GENERATE_MIPMAP
> 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.



 

-Ken