OpenGL ES EGL Spec & APIs
SK planet/Mobile Platform Dept.
OpenGL ARB and Khronos Group
• OpenGL ES
– OpenGL ES is a lightweight graphics API which is designed for Embedded
System from OpenGL which is designed for Work Station.
– OpenGL is maintained by OpenGL ARB(Architecture Review Board), OpenGL
ES is maintained Khronos Group.
OpenGL Driver and Implementation
• OpenGL Terminology(Link)
ICD Installable Client Driver, contains the entire rendering pipeline of OpenGL. This solution, while providing the highest
possible performance, was also daunting to IHVs. The Microsoft ICD kit required considerable effort to turn into a driver.
SGI's DDK is also an ICD, but comes with a sample driver (for Virge/GX) as an example.
IHV Independent Hardware Vendor, the manufacturers of 3D accelerators.
MCD Mini Client Driver, designed as an abstraction of the rasterization layer of the rendering pipeline. The MCD promised to
make developing OpenGL drivers for Windows easy for IHVs. Released for Windows/NT, it was promised, then never
delivered for Win95. The MCD also gave up considerable performance due to it's design.
PFD Pixel Format Descriptor, describes the pixel depth and buffers available.
OpenGL Utility Libraries
Prefix Name Functions
gl OpenGL API glClear,glDrawArrays,…
glu OpenGL Utility Library gluPerspective,gluLookAt
glut OpenGL Utility Toolkit glutInitDisplayMode,glutSwapBuffers
aux OpenGL Auxiliary Library auxDIBImageLoad,auxInitWindow
glew OpenGL Extension Wrangler Library glewInit, glewIsSupported
wgl/agl/cgl/glx/egl Native Interface for OpenGL wglCreateContext,wglMakeCurrent,eglCr
• OpenGL Auxiliary Library
– which was a part of the GLUT library and is now obsolete. We need to rewrite
the program using GLUT.
• The OpenGL Utility Toolkit
– GLUT (pronounced like the glut in gluttony) is the OpenGL Utility Toolkit, a window system
independent toolkit for writing OpenGL programs. It implements a simple windowing application
programming interface (API) for OpenGL. GLUT makes it considerably easier to learn about and
explore OpenGL programming. GLUT provides a portable API so you can write a single OpenGL
program that works across all PC and workstation OS platforms.
– Window system support
– Modeling support
• The OpenGL Extension Wrangler Library
– Checking extensions
• How to get WGL extension
• OpenGL Native Interface for Windows
– WGL or Wiggle is an API between OpenGL and the windowing system interface of Microsoft
EGL (Native Platform Graphics
• Native Platform Interface
– EGL™ is an interface between Khronos rendering APIs such as OpenGL ES or OpenVG and the
underlying native platform window system. It handles graphics context management, surface/buffer
binding, and rendering synchronization and enables high-performance, accelerated, mixed-mode 2D
and 3D rendering using other Khronos APIs. EGL also provides interop capability between Khronos to
enable efficient transfer of data between APIs – for example between a video subsystem running
OpenMAX AL and a GPU running OpenGL ES.
• Portable Layer for Graphics Resource Management
– EGL can be implemented on multiple operating systems (such as Android and Linux) and native
window systems (such as X and Microsoft Windows). Implementations may also choose to allow
rendering into specific types of EGL surfaces via other supported native rendering APIs, such as Xlib
or GDI. EGL provides:
• Mechanisms for creating rendering surfaces (windows, pbuffers, pixmaps) onto which client APIs can draw and
• Methods to create and manage graphics contexts for client APIs
• Ways to synchronize drawing by client APIs as well as native platform rendering APIs.
• Specifically EGL is a wrapper over the following subsystems;
– WGL – Windows GL – the Windows-OpenGL interface (pronounced wiggle)
– CGL – the Mac OS X-OpenGL interface (the AGL layer sits on top of CGL)
– GLX – the equivalent X11-OpenGL interface
• EGL not only provides a convenient binding between the operating system
resources and the OpenGL subsystem, but also provides the hooks to the
operating system to inform it when you require something, such as;
1. Iterating, selecting, and initializing an OpenGL context
2. This can be the OGL API level, software vs. hardware rendering, etc.
3. Requesting a surface or memory resource.
4. The OS services requests for system or video memory
5. Iterating through the available surface formats (to pick an optimal one)
6. You can find out properties of the video card(s) from the OS – the surfaces presented will
resides on the video card(s) or software renderer interface.
7. Selecting the desired surface format
8. Informing the OS you are done rendering and it’s time to show the scene.
9. Informing the OS to use a different OpenGL context
10. Informing the OS you are done with the resources.
EGLWindow, EGLDisplay, EGLSurface
– Abstract display on which graphics are drawn
– Single physical screen
– Initialize by querying a default display
– All EGL objects are associated with an EGLDisplay
• EGLContext(Rendering Contexts)
– EGLContext is a state machine defined by a client API
– EGLContext is associated with EGLSurfaces
• EGLSurface(Drawing Surfaces)
– Types: windows, pbuffers, pixmaps
• Windows, pixmaps: tied to native window system
– Created with EGLConfig
• Describes depth of color buffer component and types, quantities, and sizes of the ancillary buffers(depth,
multisample, stencil buffers)
– Ancillary buffers are associated with an EGLSurface
• Not EGLContext
• Interaction with native rendering
– Native rendering will always be supported by pixmap surfaces
• Pixmap surfaces have restricted capabilities and performance relative to window and pbuffer surfaces
– Native rendering will not be supported by pbuffer surfaces, since the color buffers of pbuffers are allocated internally by EGL and
are not accessible through any other means.
– Native rendering may be supported by window surfaces, but only if the native window system has a compatible rendering model
allowing it to share the back color buffer, or if single buffered rendering to the window surface is being done.
– When both native rendering APIs and client APIs are drawing into the same underlying surface, no guarantees are placed on the
relative order of completion of operations in the different rendering streams other than those provided by the synchronization
primitives discussed in section 3.8
• Shared State
– OpenGL and OpenGL ES Texture Objects
• OpenGL and OpenGL ES makes no attempt to synchronize access to texture objects. If a texture object is bound to more than
one context, then it is up to the programmer to ensure that the contents of the object are not being changed via one context
while another context is using the texture object for rendering. The results of changing a texture object while another context
is using it are undefined.
– OpenGL and OpenGL ES Buffer Objects
• hen it is up to the programmer to ensure that the contents of the object are not being changed via one context while another
context is using the buffer object for rendering. The results of changing a buffer object while another context is using it are
• Multiple Threads
– EGL guarantees sequentially within a command stream for each of its client APIs , but not between these APIs and native APIs
which may also be rendering into the same surface.
– Client API commands are not guaranteed to be atomic.
• Synchronization is in the hands of the client.
• It can be maintained at moderate cost with the judicious use of commands such as glFinish, vgFinish, eglWaitClient, and
eglWaitNative, as well as (if they exist) synchronization commands present in native rendering APIs.
• Power Management
– Power management events can occur synchronously while an
application is running. When the system returns from the power
management event the EGLContext will be invalidated, and all
subsequent client API calls will have no effect (as if no context is
– Following a power management event, calls to eglSwapBuffers,
eglCopyBuffers, or eglMakeCurrent will indicate failure by returning
EGL_FALSE. The error EGL_CONTEXT_LOST will be returned if a power
management event has occurred.
• On detection of this error, the application must destroy all contexts (by calling
eglDestroyContext for each context). To continue rendering the application must
recreate any contexts it requires, and subsequently restore any client API state and
objects it wishes to use.
• Any EGLSurfaces that the application has created need not be destroyed following a
power management event, but their contents will be invalid.
EGL Basic Usage
• The basic usage of EGL and similar API are the following;
1. (Android) Obtain the EGL interface.
• So you can make EGL calls
2. Obtain a display that’s associated with an app or physical display
3. Initialize the display
4. Configure the display
5. Create surfaces
• Front, back, offscreen buffers, etc.
6. Create a context associated with the display
• This holds the “state” for the OpenGL calls
7. Make the context “current”
• This selects the active state
8. Render with OpenGL (OpenGL not EGL calls, the OpenGL state is held by EGL context)
9. Flush or swap the buffers so EGL tells the OS to display the rendered scene. Repeat
rendering till done.
10. Make the context “not current”
11. Clean up the EGL resources
OpenGL Framebuffer(Ancillary buffer)
• Framebuffer(Ancillary buffer)
– A Framebuffer is a collection of buffers that can be used as
the destination for rendering.
Color Buffer Double buffering, stereo buffering
Depth Buffer Shadow map, internal rendering
Stencil Buffer Shadow volume, color masking, reflection
Accum Buffer Motion blur, anti-aliasing
glEnable GL_DEPTH_TEST, GL_STENCIL_TEST
EGLBoolean eglInitialize(EGLDisplay dpy, EGLint
*major, EGLint *minor);
the values of *major and *minor would be 1 and 2, respectively).
major and minor are not updated if they are specified as NULL.
EGLBoolean eglTerminate(EGLDisplay dpy);
const char *eglQueryString(EGLDisplay dpy, EGLint
EGL_CLIENT_APIS, EGL_EXTENSIONS, EGL_VENDOR, or EGL_
Rendering to Textures
EGLBoolean eglBindTexImage(EGLDisplay dpy,
EGLSurface surface, EGLint buffer);
Bind OpenGL ES Texture
EGLBoolean eglReleaseTexImage(EGLDisplay dpy,
EGLSurface surface, EGLint buffer);
Release OpenGL ES Texture
EGLBoolean eglBindAPI(EGLenum api); EGL_OPENGL_API,
EGL_OPENGL_ES_API, or EGL_OPENVG_API.
EGLenum eglQueryAPI(void); The value returned will be one of the valid api parameters to
EGLContext eglCreateContext(EGLDisplay dpy,
EGLConfig config, EGLContext share_context,
const EGLint *attrib_list);
Create a context
EGLBoolean eglDestroyContext(EGLDisplay dpy,
Destroy a context
EGLBoolean eglMakeCurrent(EGLDisplay dpy,
EGLSurface draw, EGLSurface read,
Set context to current context
EGLContext eglGetCurrentContext(void); Get current context
EGLSurface eglGetCurrentSurface(EGLint readdraw); Get current surface
EGLDisplay eglGetCurrentDisplay(void); Get current display
EGLBoolean eglQueryContext(EGLDisplay dpy,
EGLContext ctx, EGLint attribute, EGLint
Return attribute list
EGLBoolean eglWaitClient(void); The same result can be achieved using client API -specific calls
such as glFinish
EGLBoolean eglWaitGL(void); EGLenum api = eglQueryAPI();
Posting the color buffer
EGLBoolean eglSwapBuffers(EGLDisplay dpy,
Posting to a Window
When native window resizing, called automatically
EGLBoolean eglCopyBuffers(EGLDisplay dpy,
EGLSurface surface, EGLNativePixmapType
Copying to a Native Pixmap
EGLBoolean eglSwapInterval(EGLDisplay dpy, EGLint
Control swap buffer interval