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.

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

\ No newline at end of file