[Bf-committers] glGetIntegerv(GL_TEXTURE_2D. &id) is incorrect.
jason.a.wilkins at gmail.com
Wed Jul 24 04:58:18 CEST 2013
I favor creating a detailed policy for Blender's OpenGL state. That's
something I've been thinking about and working on. Then we can avoid
saving and restoring state all together.
I have found places were Blender needs to know the state for purposes other
than restoring it, but in those cases I've wrapped the function in a
function that latches the state in main memory. There are only a couple of
these though (and one of them does double duty as a replacement for
glDepthFunc in ES).
The are only a couple of places left in my branch that need Push/PopAttrib.
One of those is a real monster. Even though I wrote it back in GSoC 2010,
I'm not happy about untangling it :-)
On Mon, Jul 22, 2013 at 6:02 PM, Mitchell Stokes <mogurijin at gmail.com>wrote:
> I'm all for getting rid of unneeded glGet calls. Really, we should strive
> to only use glGet calls in initialization type functions since they slow
> down normal program execution. If we really need to save a value, we should
> use the (deprecated) glPush/PopAttrib, or use EXT_direct_state_access to
> avoid the issue entirely.
>  https://www.opengl.org/registry/specs/EXT/direct_state_access.txt
> On Mon, Jul 22, 2013 at 3:44 PM, Jason Wilkins <jason.a.wilkins at gmail.com
> > GL_TEXTURE_2D is the enable bit, not the bound texture.
> > So, the code...
> > glGetIntegerv(GL_TEXTURE_2D. &prev_tex_id)
> > ... also sometimes written as ...
> > prev_tex_id = glaGetOneInteger(GL_TEXTURE_2D)
> > ... is incorrect, I think what is meant is the binding state...
> > glGetIntegerv(GL_TEXTURE_BINDING_2D, &prev_tex_id)
> > ... or ...
> > prev_tex_id = glaGetOneInteger(GL_TEXTURE_BINDING_2D)
> > The fact that Blender still works tells me that this code (and the later
> > code rebinding the previous texture) is probably unneeded and can be
> > removed. It must be that all functions that draw with a texture map do
> > call other functions that change the texture before they need the
> > texture again.
> > This is especially apparent since any call to a function that has this
> > will result in the bound texture being either 0 or 1 (The value of
> > and GL_TRUE).
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers