Talk:OpenGL Programming/APIs, Libraries and acronyms

Landscape
The way I see it is:

window/context management: OpenGL -> WGL, GLX, CGL/AGL -> GLUT, GLFW, freeglut

extensions: OpenGL -> GLEW, Glee

and on top of those two branches, there are render engines (e.g. OGRE) and scenegraphs (e.g. OpenSG, OpenScenegraph). And on top of render engines and scenegraphs, there are game engines etc. (e.g. OgreKit; however, many game engines implement their own render engine; thus, this distinction isn't always useful).

OpenCL is next to OpenGL but doesn't have many libraries on top of it.

Then there is:

OpenGL ES (and OpenVG) -> EAGL -> EGL -> render engines -> game engines

Where EAGL would correspond to the level of WGL, GLX, CGL/AGL, and EGL would correspond to the level of GLUT, GLFW, freeglut

WebGL is very close to OpenGL ES but currently doesn't require an API such as EGL, instead it has HTML5 on top of it.

I guess, currently, the OpenGL ES branch is a separate branch from the OpenGL branch. In the road map of Khronos, however, the idea is to use EGL to communicate buffers between OpenGL, OpenCL, OpenGL ES and WebGL. A good illustration is slide 7 of the "An Interactive OpenCL Overview" presentation on this page.

I've never used Mesa3D. Apparently, it is difficult to integrate in such a scheme because you can use it in various ways.

Direct3D is probably an alternative up to (and including) the GLUT, GLFW, freeglut level.

I'm not sure EGL is currently used with OpenGL. The text says: "EGL should provide a single interface to embedded systems' OpenGL implementation, for instance Android." Does this refer to OpenGL ES or is it really OpenGL?

At least, that's how I understand the situation. :) --Martin Kraus (discuss • contribs) 20:59, 13 August 2011 (UTC)


 * Thanks! I added several of your remarks in the document, and referenced Direct3D and Mesa3D in a separate section.
 * I see EGL support in GLFW. This layer is getting increasing support for mobile platforms, so I don't think separating OpenGL ES / EGL is appropriate.  I fixed "OpenGL" -> "OpenGL ES" when discussing EGL though.
 * EGL is not at the same level than GLUT&cie: you need platform-specific code to initialize it, so (for instance) it is typically not a good candidate to work with in the tutorials. I wanted to make this distinction because I hesitated myself. Beuc (discuss • contribs) 10:50, 15 August 2011 (UTC)


 * I've only programmed OpenGL ES 2.0 on iOS with EAGL (and the POWERVR SDK which uses EAGL on iOS); thus, I don't know. However, the "OpenGL ES 2.0 Programming Guide" states on page 35: "As part of the family of APIs provided by the Khronos Group for developing content, a (mostly) platform-independent API, EGL, is available for managing drawing surfaces (windows are just one type; we'll talk about others later)." And later on page 36: "EGL provides a "glue" layer between OpenGL ES 2.0 (and other Khronos graphics APIs) and the native windowing system running on you computer, like the X WIndow System common on GNU/Linux systems, Microsoft Windows, or Mac OS X's Quartz." On the other hand, that book was written when the only implementation of OpenGL ES 2.0 was the AMD emulator; thus, it probably doesn't reflect current practice. --Martin Kraus (discuss • contribs) 11:53, 15 August 2011 (UTC)

Title?
I'm not so sure about the title. Shouldn't it rather refer to "APIs" or graphics libraries? --Martin Kraus (discuss • contribs) 21:03, 13 August 2011 (UTC)
 * Maybe "APIs and libraries", yes indeed.Beuc (discuss • contribs) 10:50, 15 August 2011 (UTC)

Hardware Support
The "POWERVR Khronos OpenGL ES 2.0 SDKs" are also available for Linux and Windows Vista/XP, where the SDK offers an emulation of OpenGL ES 2.0 on desktops.

Another OpenGL ES 2.0 emulator for Windows was developed by AMD; it is no longer supported but still available in the wiki for the OpenGL ES 2.0 Programming Guide.

And, in a way, Xcode includes an emulator of OpenGL ES (and iOS) on MacOS X.

--Martin Kraus (discuss • contribs) 21:14, 13 August 2011 (UTC)


 * Thanks again! I moved and clarified the part of Mesa3D "emulation".  Being a free software enthusiast, I don't feel like discussing (advertising) proprietary solutions at length, and I don't think I know enough to discuss these parts, so maybe I'll incorporate this later.