xuxiandi / angleproject

Automatically exported from code.google.com/p/angleproject
Other
0 stars 0 forks source link

GenTextures can return previously-used textures #223

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Haven't tested this, but it looks like GenTextures can return texture object 
names that were previously used with BindTextures (but not created with a 
previous GenTextures). It seems like it actually overwrites (and NULL out) the 
previously bound texture with that name.

Original issue reported on code.google.com by jbauman@chromium.org on 6 Oct 2011 at 8:21

GoogleCodeExporter commented 9 years ago
I've had this happen without any calls to BindTextures. I have code which tries 
to call glGenTextures(1, &textureName) 27 times during the course of execution 
and texture names 1 - 25 are returned correctly. Rather than returning 26 for 
the following call however, I get 20 again, followed then by 26 - never 
reaching 27.  Consequently the texture originally bound to 20 is lost.  
Curiously, this only seems to happen in release mode.   

Original comment by guyfollo...@gmail.com on 24 Jun 2012 at 1:26

GoogleCodeExporter commented 9 years ago
I don't know if this causes more problems than it solves but I fixed the issue 
I was having by deleting "return handle" from HandleAllocator::allocate so that 
it always increments mNextValue when returning.  

Original comment by guyfollo...@gmail.com on 24 Jun 2012 at 1:48

GoogleCodeExporter commented 9 years ago
It shouldn't do that unless texture 20 was deleted. You could set a breakpoint 
in ResourceManager::deleteTexture and see why that would be happening.

Original comment by jbauman@chromium.org on 24 Jun 2012 at 9:32

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Yeah, it was my fault - I have a texture object which stores the texture id as 
a member variable.  When loading a texture, the first thing it does is check if 
the id != 0 and disposes of it if it is.  Unfortunately I wasn't initializing 
the value of the member variable so it contained garbage which, for some 
reason, happened to take a value of 20 for the 26th object.  Whoops, but thanks!

Original comment by guyfollo...@gmail.com on 30 Jun 2012 at 11:55

GoogleCodeExporter commented 9 years ago
Merging in to my new issue for this.

Original comment by jmad...@chromium.org on 17 Mar 2015 at 8:36