[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.
-Ken
> (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