diff -r 4816d766a08a -r f345bda72bc4 Symbian3/PDK/Source/GUID-0B2421FD-8431-5DDA-9FE3-046734AE495E.dita --- a/Symbian3/PDK/Source/GUID-0B2421FD-8431-5DDA-9FE3-046734AE495E.dita Tue Mar 30 11:42:04 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-0B2421FD-8431-5DDA-9FE3-046734AE495E.dita Tue Mar 30 11:56:28 2010 +0100 @@ -1,83 +1,83 @@ - - - - - -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 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