diff -r 000000000000 -r 89d6a7a84779 Symbian3/SDK/Source/GUID-EF62BF88-3687-505D-8BD7-EEDF36246E56.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-EF62BF88-3687-505D-8BD7-EEDF36246E56.dita Thu Jan 21 18:18:20 2010 +0000 @@ -0,0 +1,132 @@ + + + + + +Graphics +Hardware AccelerationThis topic describes some of the issues surrounding the use of +graphics hardware to improve graphics performance. It also provides a summary +of the components that device creators need to adapt to take advantage of +graphics hardware. +
Background

Graphics acceleration hardware

A +graphics accelerator or Graphics Processing Unit (GPU) is a dedicated hardware +processor that works in parallel with the main processor (CPU). By relieving +the CPU of highly intensive graphics processing, a GPU makes it is possible +to achieve sophisticated screen displays (such as video, animated graphics +and 3D games) without compromising other aspects of performance.

Animations

Animation +involves transferring and manipulating large amounts of data (stored as bitmaps +or instructions) from one area of memory and putting them into another (the +screen buffer). Frame rates may be between 10 and 30 frames per second (depending +on requirements and sources).

Composition

Manufacturers +of smartphones face the complexity of displaying on the screen a mixture of +different types of content, such as streaming video, the camera viewfinder +and regular UI elements with animated icons. These different types of content +come from different places—such as multimedia sources (streaming video), camera +hardware, the Window Server and EGL (3D and vector graphics). The different +types of content are displayed in different areas of the screen and are updated +by different processes. The graphics system must be capable not only of creating +sophisticated graphical output from each source simultaneously but also of +composing (compositing) them at up to 30 frames per second. For an introduction +to how ScreenPlay handles this challenge, see Graphics +Composition.

Optimization

GPUs work best when +they do so uninterrupted. They usually have a 'long processing pipe' (a lot +of data cached in memory) and flushing it or allowing it to empty reduces +effectiveness. This can be avoided by avoiding the following:

    +
  • Context switching. +The working data (such as color information, vertex positions, transformations +and textures) is known as the context. If more than one application +wants to use the processor at the same time, the processor must swap between +them. This involves the processor saving the context from one application, +flushing its buffers, and loading the context from the next. Context switching +is time consuming and disruptive.

  • +
  • Copying and reformatting +data. Changing the format and copying pixel data involves time and memory. +If the GPU and CPU cannot share memory and data formats, much time, processing +power and memory is required to copy and convert data.

  • +

ScreenPlay avoids context switching and reformatting and copying +data wherever possible.

Hardware variety

The combination +of hardware acceleration, animation and composition would be a substantial +challenge in a fixed, dedicated hardware architecture. The Symbian platform, +however, is designed to operate on a variety of hardware architectures, only +some of which are capable of graphics acceleration and processing. The Symbian +graphics subsystem can be customized to take advantage of a variety graphics +processing hardware. Customization is via 'back end' components which do not +affect the public API.

+
The hardware adaptation components

Here we provide +information about which graphics components device creators can adapt or replace. +Components that can be adapted or replaced to suit the hardware are generally +called adaptations. Adaptable and replaceable components that do not +depend on the hardware are called customizations and are indicated +by an asterisk (*) in the following table.

The details vary depending +on whether the ScreenPlay or non-ScreenPlay variant +is in use.

+ + + +ScreenPlay +Non-ScreenPlay + + + + +OpenGLES Implementation +OpenGLES Implementation + + +OpenVG Implementation +OpenVG Implementation + + +EGL Implementation +EGL Implementation + + +Screen Driver +Screen Driver + + +Extended Bitmap Rasterizer Plug-in +Extended Bitmap Rasterizer Plug-in + + +DirectGDI Adaptation + + + +Graphics Resource Adaptation + + + + +OpenWF Composition Engine + + + +Surface Manager + + + +Surface Update + + + +Render Stages* + + + + +
+
+Graphics +Concepts +The ScreenPlay +Architecture +The Non-ScreenPlay +Architecture +
\ No newline at end of file