EGL -Collection Overview

EGL -Collection OverviewEGL is an interface between EGL client APIs (such as OpenGL ES -and OpenVG) and an underlying native platform window system. EGL is independent -of definitions and concepts specific to any native window system or rendering -API. -

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.

-EGL - Collection -OpenVG Collection - -OpenGLES -Collection + + + + + +EGL Collection +OverviewEGL is an interface between EGL client APIs (such as OpenGL ES +and OpenVG) and an underlying native platform window system. EGL is independent +of definitions and concepts specific to any native window system or rendering +API. +

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.

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.

+EGL + Collection +OpenVG Collection + +OpenGLES +Collection +Graphics +Composition

\ No newline at end of file