diff -r ae94777fff8f -r 59758314f811 Symbian3/PDK/Source/GUID-0B2421FD-8431-5DDA-9FE3-046734AE495E.dita --- a/Symbian3/PDK/Source/GUID-0B2421FD-8431-5DDA-9FE3-046734AE495E.dita Fri Jun 11 12:39:03 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-0B2421FD-8431-5DDA-9FE3-046734AE495E.dita Fri Jun 11 15:24:34 2010 +0100 @@ -1,83 +1,74 @@ - - - - - -Window -Surface ImplementationThis topic provides an introduction to implementing EGL window -surfaces on the Symbian platform. These are used for onscreen rendering into -windows that are provided by the Symbian platform (rather than EGL). The details -of how to implement window surfaces depend on whether the ScreenPlay variant -is in use. -

Target audience: Device creators.

-
Symbian windows

Window surfaces are created by -the eglCreateWindowSurface() function, to which is passed -a handle to a window provided by the Symbian Window -Server. Key Window Server classes include the following:

    -
  • RWindow, -which is a handle to a standard window.
  • -
  • RWsSession, -which is the Window Server session class. This is required to create Window -Server objects.
  • -
  • CWsScreenDevice, -which is a Window Server client-side object representing the screen.
  • -
-
Non-ScreenPlay

In the non-ScreenPlay variant -there is no composition engine and both Symbian API drawing (for example, -through CWindowGc) and EGL client API drawing are rendered -to a single display. The EGL implementation can achieve this in a number of -ways, including:

    -
  • Using Direct Screen -Access (DSA) to render the EGL client API drawing directly to the screen. -This is done in cooperation with the Window Server, which provides clipping -instructions. This approach is particularly suitable when graphics acceleration -hardware is available.

  • -
  • Rendering the EGL client -API drawing to an offscreen CFbsBitmap and then calling -a Window Server API to blit the CFbsBitmap onto the screen, -with any necessary clipping.

  • -
-
ScreenPlay

ScreenPlay has introduced the Graphics Composition Collection, -which enables a number of surfaces to be arranged in layers and to -be composed together to produce the final output on the display. In this section, -these surfaces are called composition surfaces in order to distinguish -them from EGL surfaces. Each composition surface is mapped to memory, which -can be specialized graphics memory for faster performance.

All -Window Server drawing (such as the application UI) is rendered to a composition -surface called the UI surface, which is usually the topmost layer and -can be semi-transparent.

When the EGL implementation creates an EGL -window surface for a Symbian window (represented by RWindow), -the EGL implementation must do the following:

    -
  • Create a new composition -surface with the same width and height as the RWindow.

  • -
  • Position the composition -surface in a layer below the UI layer, directly below the RWindow.

  • -
  • Make the RWindow transparent -in order for the composition surface to show through.

  • -

All of the EGL client API drawing to the EGL window surface -is then rendered to the composition surface and the application's UI appears -as a semi-transparent layer above it.

When a window is resized, a new -composition surface needs to be created with the new width and height, and -positioned as a layer below the RWindow in place of the -previous composition surface.

A composition surface can have more than -one pixel buffer associated with it (each buffer has the same dimensions). -For an EGL window surface, the composition surface should have two buffers -for double-buffered drawing. This means, for example, that OpenVG commands -can draw to the back buffer, while the front buffer is being -composed to the screen.

-
-EGL Porting -Guide -Graphics -Composition Collection Overview -Implementing -eglCreateWindowSurface -Implementing -eglSwapBuffers + + + + + +Window Surface ImplementationThis topic provides an introduction to implementing EGL +window surfaces on the Symbian platform. These are used for onscreen +rendering into windows that are provided by the Symbian platform (rather +than EGL). The details of how to implement window surfaces depend +on whether the ScreenPlay variant is in use. +

Target audience: Device creators.

+
Symbian windows

Window surfaces are created +by the eglCreateWindowSurface() function, to which +is passed a handle to a window provided by the Symbian Window Server. Key Window Server classes include the following:

    +
  • RWindow, which is a handle to a standard window.
  • +
  • RWsSession, which is the Window Server session class. This is required to create +Window Server objects.
  • +
  • CWsScreenDevice, which is a Window Server client-side object representing the screen.
  • +
+
Non-ScreenPlay

In the non-ScreenPlay +variant there is no composition engine and both Symbian API drawing +(for example, through CWindowGc) and EGL client +API drawing are rendered to a single display. The EGL implementation +can achieve this in a number of ways, including:

    +
  • Using Direct +Screen Access (DSA) to render the EGL client API drawing directly +to the screen. This is done in cooperation with the Window Server, +which provides clipping instructions. This approach is particularly +suitable when graphics acceleration hardware is available.

  • +
  • Rendering the +EGL client API drawing to an offscreen CFbsBitmap and then calling a Window Server API to blit the CFbsBitmap onto the screen, with any necessary clipping.

  • +
+
ScreenPlay

ScreenPlay has introduced the Graphics Composition +Collection, which enables a number of surfaces to be +arranged in layers and to be composed together to produce the final +output on the display. In this section, these surfaces are called composition surfaces in order to distinguish them from EGL surfaces. +Each composition surface is mapped to memory, which can be specialized +graphics memory for faster performance.

All Window Server +drawing (such as the application UI) is rendered to a composition +surface called the UI surface, which is usually the topmost +layer and can be semi-transparent.

When the EGL implementation +creates an EGL window surface for a Symbian window (represented by RWindow), the EGL implementation must do the following:

    +
  • Create a new +composition surface with the same width and height as the RWindow.

  • +
  • Position the +composition surface in a layer below the UI layer, directly below +the RWindow.

  • +
  • Make the RWindow transparent in order for the composition surface +to show through.

  • +

All of the EGL client API drawing to the EGL window +surface is then rendered to the composition surface and the application's +UI appears as a semi-transparent layer above it.

When a window +is resized, a new composition surface needs to be created with the +new width and height, and positioned as a layer below the RWindow in place of the previous composition surface.

A composition surface can have more than one pixel buffer associated +with it (each buffer has the same dimensions). For an EGL window surface, +the composition surface should have two (or more) buffers for double-buffered +drawing. This means, for example, that OpenVG commands can draw to +the back buffer, while the front buffer is being composed to the screen.

+
+EGL +Porting Guide +Graphics +Composition Collection Overview +Implementing +eglCreateWindowSurface +Implementing +eglSwapBuffers
\ No newline at end of file