Eero Pajarre wrote:
>
> In my application I noticed than when I
> repeat a mixture of glGenTextures and then
> glDeleteTextures, my texture id numbers from
> glGenTextures seem to go up all the time.
> (I had specific conditions, like I hardly ever
> had the texture to be deleted as the current
> texture.)
>
> When I tried to track what is happening using the debugger
> I noticed that in texobj.c the gl_DeleteTextures never
> called gl_free_texture_object, the reason being that the
> RefCount field was always 1 when here.
>
> It appears that the texture object is generated with
> RefCount=1 and all the other operations are symmetric
> pairs, so I don't really understand how the value is going
> to get to 0 as expected here...
>
> I still assume I am missing something, but what?
If you're calling glDeleteTexture() on a texture which
is currently bound to a texture target (GL_TEXTURE_[123]D)
then the texture can't be deleted until the texture object
is unbound. Try unbinding the texture object first with
glBindTexture(GL_TEXTURE_2D, 0) and trace through
glDeleteTextures() again.
> PS.
>
> The current CVS doesn't compile on WIN32 using
> the Makefile.fx
>
> fixes needed:
> Lines 70 and 149 in glthreads should refer to same WIN32 symbol.
> (I changed it here to use WIN32, but would WIN32_THREADS
> be better??)
It should be WIN32_THREADS everywhere. To actually enable thread
safety on Win32 you'll need the equivalent of -DWIN32_THREADS in
your project/makefile.
> Line 162 in glthreads should be:
> #define _glthread_DECLARE_STATIC_MUTEX(name) static _glthread_Mutex name = {0}
> (notice the braces at the end.)
>
> I will look at how to really implement the macros.
OK. I don't think it's urgent though.
I've been spending a lot of time on thread safety for Linux. However,
only the OS/Mesa driver is truly thread safe at this time. The other
drivers will need some mutex locks.
-Brian
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
