[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: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

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: