On Wed, May 19, 2010 at 6:53 PM, Gregg Tavares <email@example.com
> On Wed, May 19, 2010 at 6:45 PM, Kenneth Russell <firstname.lastname@example.org
>> On Wed, May 19, 2010 at 6:31 PM, Cedric Vivier <email@example.com
>> > On Thu, May 20, 2010 at 08:52, Kenneth Russell <firstname.lastname@example.org
>> >> On Wed, May 19, 2010 at 5:38 PM, Cedric Vivier <email@example.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
>> This proposal is not workable.
> Are you objecting to the design or specifically to overloading
> 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.