[Public WebGL] createTextures vs. genTexture 2^32 limit

Kenneth Russell [email protected]
Mon Apr 23 16:15:47 PDT 2012

On Sun, Apr 15, 2012 at 8:18 AM, Glenn Maynard <[email protected]> wrote:
> In OpenGL ES, genTexture appears to be underdefined after the first 2^32
> calls:
>> void GenTextures( sizei n, uint *textures ); returns n previously unused
>> texture object names in textures. These names are marked as used, for the
>> purposes of GenTextures only, ...
> That is, even after a glDeleteTextures() call on a texture, glGenTextures
> will never return the same value again.

That's not correct. DeleteTextures() specifies (GLES 2.0.25, section
3.7.13 "Texture Objects", page 85):

"After a texture object is deleted, it has no contents or
dimensionality, and its name is again unused."

DeleteTextures() makes the name available from return from GenTextures again.

>  However, the ES spec doesn't appear
> to say what happens if it runs out--if you overflow uint.
> It's definitely possible to call createTexture() 2^32 times; in Chrome 18 on
> my system, it takes about three hours.  This shouldn't happen in
> well-written programs, but it still needs to be defined.
> I'm not actually concerned about ES's behavior here, since WebGL's texture
> objects don't expose integer texture IDs.  However, the underdefined
> overflow problem is inherited by WebGL, since createTexture is defined in
> terms of genTextures.
> WebGL can avoid this by not defining createTexture() in terms of
> glGenTextures.  Instead, say: "Create a WebGLTexture object and initialize
> it with a texture object name not in use by any other WebGLTexture in this
> context."  That's still valid, since OpenGL doesn't actually require that
> you use glGenTextures.
> The same applies to the other create* functions as well, of course.

I don't think a spec change is warranted in this area. The underlying
GLES semantics seem sufficient.


> (I'd call this one low-priority, but a good thing to tighten up.)
> --
> Glenn Maynard

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list