Bug 45558 - Remove Platform3DObject typedef from GraphicsContext3D
Summary: Remove Platform3DObject typedef from GraphicsContext3D
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebGL (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Kenneth Russell
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-10 12:33 PDT by Kenneth Russell
Modified: 2011-02-08 11:51 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kenneth Russell 2010-09-10 12:33:32 PDT
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".
Comment 1 Chris Marrin 2010-09-10 13:37:41 PDT
(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.
Comment 2 Kenneth Russell 2010-09-13 12:07:18 PDT
(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.
Comment 3 Zhenyao Mo 2011-02-08 11:51:02 PST
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.