EGL Collection Overview

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).

Figure 1. 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.

Symbian^3 introduces ScreenPlay, the new graphics architecture. This has a composition engine, which enables composition surfaces to be arranged in layers and to be composed together to produce the final output on the display. All native Symbian drawing (such as the application UI) is rendered to a special composition surface called the UI surface, which is the topmost layer and can be semi-transparent.

In a ScreenPlay environment, EGL window surfaces are implemented as composition surfaces. This means that it is possible to use the native Symbian drawing APIs (CWindowGc) to create semi-transparent UI content over the EGL window surface onto which the OpenVG and OpenGL ES content is rendered. See the Coverflow; using ScreenPlay application for an example of this.

In the non-ScreenPlay environment, it is not possible to use the native Symbian APIs to create semi-transparent UI content over the EGL window surface. A different solution must therefore be used; for example, using Khronos rendering APIs to create the UI content and direct it onto the EGL window surface or using the Symbian APIs to create opaque child windows.

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.