[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Explicit unboxing for object identifiers

On Sun, Jan 8, 2012 at 9:53 AM, Rehno Lindeque <rehno.lindeque@gmail.com> wrote:

First, let me be clear that I'm not trying to re-open the old argument
over whether uniform locations and other object identifiers should be
boxed or unboxed. I'm pretty happy with hiding the object handles in

FWIW, I don't think this is the best way to think about WebGL resources. As far as the API and users are concerned, they represent the resource itself, not a handle in another API. If they happen to be implemented under the hood as an OpenGL unsigned int handle, that's an implementation detail; a Direct3D implementation could be entirely different and have no persistent, unique value to use as a handle.
At the moment I don't think the spec actually denotes whether two
WebGLUniformLocation objects could be compared. For example, when you
get two uniform locations for the same uniform name, does the
implementation return a reference to the same object? If it did, one
could test for location1 === location2

You can't. This has been made explicit in the current draft of the spec (https://www.khronos.org/registry/webgl/specs/latest); getUniformLocation says "Return a new WebGLUniformLocation", so it doesn't return the same object twice.

Furthermore, in glQuery I would like to use uniform locations as keys
in a simple _javascript_ object so it would be ideal for me if I could
write code like:

 Âvar locations = {};
 Âlocations[uniformLocation.handle] = data;
 Â// possibly, locations[uniformLocation.toHandle()] = data;


locations[[program,location]] = data;

where program and location are the values you'd pass to getUniform.

In principle, WebGL objects could retain references to this sort of information (the context for all of them; the program and name for uniforms, and so on), so you could say locations[[loc.program, loc.name]]. I don't know if that'd be worthwhile.

Glenn Maynard