EGL +Collection Overview

EGL is an open standard developed by the Khronos Group, which is a member-funded +industry consortium. Khronos creates open standard, royalty-free APIs to help +write and execute dynamic media on a wide variety of platforms and devices. +For more information about EGL operations, functions, errors, versions and +header files, see http://www.khronos.org/egl/.

In this documentation the term EGL client API is used to mean a +rendering API, such as OpenGL ES or OpenVG, that is a client of EGL.

Introduction to EGL on the Symbian platform

EGL +provides:

Mechanisms that create +rendering surfaces onto which EGL client APIs can draw and which they can +share.
Methods that create +and manage graphics contexts for EGL client APIs.
Methods that synchronize +drawing by EGL client APIs and Symbian APIs (such as CWindowGc).

One of the purposes of EGL is to provide a means to create EGL client +API rendering contexts, and associate them with drawing surfaces. EGL defines +three types of drawing surfaces collectively referred to as EGLSurfaces. +These are:

Window surfaces, +which are used for on-screen rendering into windows that are provided by the +Symbian platform (rather than EGL) .
Pbuffer surfaces, +which are used for off screen rendering and are entirely provided by EGL.
Pixmap surfaces, +which are used for off screen rendering into pixmap buffers that are provided +by the Symbian platform (rather than EGL).

Some key points to note include:

EGL objects and their +related context state cannot be used outside of the address space in which +they are created.
EGL enables sharing +of certain types of context state among contexts existing in a single address +space.

Thread-safety

Currently EGL and its client APIs are +only guaranteed to work correctly on the Symbian platform when they are within +a single thread. EGL guarantees sequential ordering within a command stream +for each of the EGL client APIs. However, there is no guarantee of sequential +ordering between EGL client APIs and Symbian APIs which render into the same +surface.

EGL client API commands may be asynchronous, in order to +prevent impairing the interactive use of the windowing system by the user. +For example, otherwise rendering a large texture mapped polygon on a system +with no graphics hardware, or drawing a large OpenGL ES vertex array, could +prevent a user from invoking a menu soon enough to be usable.

Synchronization +depends on the client—it can be maintained at moderate cost with the careful +use of commands such as glFinish, vgFinish, eglWaitClient, +and eglWaitNative, as well as synchronization commands present +in the Symbian APIs. The EGL client API and Symbian API rendering can be done +in parallel if the client does not prevent it with explicit synchronization +calls. Some performance degradation may be experienced when there is unnecessary +switching between EGL client APIs and Symbian API rendering.

Architectural relationships

The following diagram +shows the key EGL relationships and dependencies within the Symbian platform. +On the Symbian platform, OpenGL ES, OpenVG and EGL all have a component (shown +in blue) that declares the interface, and all require an implementation that +implements that interface (shown in green).

+ Key EGL relationships and dependencies + +

The EGL Interface +component provides a consistent interface to EGL on the Symbian platform, +enabling cross-device compatibility. The component includes the Khronos-released +header files (which incorporate some minor changes, such as to the comments). +It also provides some Symbian-specific header files and some other files (such +as LIB, DEF and MMP files) and UIDs. It does not provide any implementations +of the APIs.

The EGL Interface component includes the header files +for EGL 1.2, 1.3 and 1.4 (which is used by default). The main advantage of +EGL 1.4 over previous versions is the introduction of a preserve buffer flag. +When supported by the implementation, an EGL window surface can have its color +buffer preserved from one frame to the next. This means that the client does +not need to send the entire drawing instructions for each frame. Instead the +client can simply send the drawing operations for what changes in each frame +compared to the previous one. This can reduce the memory footprint and the +CPU overhead when an EGL client API renders successive frames.