Bug 45558 – Remove Platform3DObject typedef from GraphicsContext3D

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebGL

[Kenneth Russell]

The Platform3DObject typedef in the GraphicsContext3D header was intended to provide an abstraction layer over what are known in the OpenGL API as "server-side objects" like textures, buffers, programs, etc. However, its use in the header is inconsistent; for example, createProgram returns "unsigned" where useProgram takes Platform3DObject. Additionally, since GraphicsContext3D was introduced, it has become clear that its intent is to expose OpenGL ES 2.0 semantics, meaning that the Platform3DObject abstraction is unnecessary and clients can just use "int" or "unsigned" depending on what the underlying OpenGL API produces or consumes. Platform3DObject causes problems in client code which uses GraphicsContext3D, because instead of just being able to forward declare "class GraphicsContext3D" in a header, one must include GraphicsContext3D.h just to pick up the Platform3DObject typedef. In summary, Platform3DObject should simply be removed and replaced with "unsigned".

[Chris Marrin]

(In reply to comment #0)
> The Platform3DObject typedef in the GraphicsContext3D header was intended to provide an abstraction layer over what are known in the OpenGL API as "server-side objects" like textures, buffers, programs, etc. However, its use in the header is inconsistent; for example, createProgram returns "unsigned" where useProgram takes Platform3DObject. Additionally, since GraphicsContext3D was introduced, it has become clear that its intent is to expose OpenGL ES 2.0 semantics, meaning that the Platform3DObject abstraction is unnecessary and clients can just use "int" or "unsigned" depending on what the underlying OpenGL API produces or consumes. Platform3DObject causes problems in client code which uses GraphicsContext3D, because instead of just being able to forward declare "class GraphicsContext3D" in a header, one must include GraphicsContext3D.h just to pick up the Platform3DObject typedef. In summary, Platform3DObject should simply be removed and replaced with "unsigned".

The reason for Platform3DObject was to make it possible to support other object models, for instance, the one used by D3D. Do you believe directly supporting such a model is no longer necessary, given ANGLE? If so, then I'm fine with this change.

[Kenneth Russell]

(In reply to comment #1)
> The reason for Platform3DObject was to make it possible to support other object models, for instance, the one used by D3D. Do you believe directly supporting such a model is no longer necessary, given ANGLE? If so, then I'm fine with this change.

Yes, I believe this is not necessary. ANGLE provides an existence proof that it is possible to build OpenGL ES 2.0 semantics on top of D3D, so GraphicsContext3D can standardize on exposing OpenGL semantics.

[Zhenyao Mo]

After we switch to use GC3D types and defined Platform3DObject as GC3Duint (same as GLuint), Platform3DObject is no longer platform dependent; however, discussed with kbr offline and because there are now more typedefs in GC3D, it's more valuable to have this typedef.  Closing this bug then.