diff -r 43e37759235e -r 51a74ef9ed63 Symbian3/SDK/Source/GUID-2C443E6F-BC3D-5252-8098-9F850AA88A35.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-2C443E6F-BC3D-5252-8098-9F850AA88A35.dita Wed Mar 31 11:11:55 2010 +0100 @@ -0,0 +1,251 @@ + + + + + +Window +Server Component OverviewThe Window Server manages the use of the screen and input devices +by applications and controls and co-ordinates access. +
Architecture

The +architecture of the Window Server varies depending on whether you are using +the ScreenPlay (NGA) or non-ScreenPlay variant. +However, with a few exceptions, the client-side API is the same in both variants. +Both variants use an improved version of the Window Server, sometimes known +as WSERV2, which was introduced in Symbian^2 (Symbian OS +v9.4).

The following diagram provides an overview of the Window Server +architecture in ScreenPlay.

+ The Window Server in ScreenPlay + +

Below we list some of the key features of the Window Server, including +differences between the two architectures. The term surface is used +in ScreenPlay for a hardware-independent memory buffer for holding an image +or part of a scene. The UI surface is a special surface onto which +the Window Server renders all of the UI content. It is created automatically +during system start up. An external surface is any other surface—for +example, a surface that holds a video or to which OpenGL ES content is rendered.

    +
  • The Window Server has +a render stage framework, which enables the last stage of the Window Server +rendering to be customizable through plug-ins called render stages. +These can be chained to form a rendering pipeline, which takes the drawing +operations that are produced by the Window Server and ultimately passes them +to the UI surface. Render stages can selectively filter, modify, or redirect +the draw operation stream, as required—for example, to perform transition +effects (TFX).

  • +
  • In ScreenPlay, composition +takes place in two stages. First, the render stages render the drawing to +the UI surface. Then the composition engine combines the UI surface and any +external surfaces into elements (sometimes called layers) and composes +them to the screen. This enables the composition to be performed in software +or hardware accelerator chips.

  • +
  • In the non-ScreenPlay +variant, the concept of surfaces is not used and the Window Server composes +directly onto the frame buffer which is then displayed on the screen.

  • +
  • There are differences +in the plug-in framework APIs in the two architectures. In addition, in ScreenPlay, +fading effects are implemented by using render stages, whereas when ScreenPlay +is not enabled they are implemented by using a separate fader plug-in type +(not shown on the diagram).

  • +
  • In ScreenPlay, the Window +Server provides advanced pointer features, such as support for multiple pointers +and proximity and pressure coordinates. The non-ScreenPlay variant does not +provide this support.

  • +
  • ScreenPlay provides +support for externally connected displays, such as TV-out. The non-ScreenPlay +variant considers the size of each display to be fixed. However, for High-Definition +Multimedia Interface (HDMI) and composite video connectors, there are a range +of resolutions that can change dynamically. ScreenPlay provides an optional +feature that supports switching between resolutions at runtime and notifications +to Window Server clients when there are changes to the resolution and connectedness.

  • +
+
Building the +ScreenPlay and non-ScreenPlay variants

To build the ScreenPlay +version of the Window Server components, declare the following macros in the Symbian_OS.hrh file.

SYMBIAN_BUILD_GCE +SYMBIAN_GRAPHICS_BUILD_OPENWF_WSERV +

This causes the ScreenPlay versions of the components in the +Graphics package to be built in addition to the non-ScreenPlay components. +Specifically the SYMBIAN_BUILD_GCE macro causes the ScreenPlay +version of the Window Server to be built. This means that the w32_nga.mmp and wserv_nga.mmp files +are built. These define a second macro, SYMBIAN_GRAPHICS_GCE, +which causes the ScreenPlay Window Server classes to be built.

To include the ScreenPlay versions when building +ROM, use the SYMBIAN_GRAPHICS_USE_GCE flag.

+
Selecting the +ScreenPlay variant in the emulator

To select the ScreenPlay version +of the component in the emulator, add the following line to the epoc.ini file:

SYMBIAN_GRAPHICS_USE_GCE ON
+
Executables

This +section lists the main Window Server executables. For clarity, these are divided +into three groups.

Window Server executable and client-side libraries

+ + + +Executable +LIB +Description + + + + +

wserv_nga.exe

+

+

The ScreenPlay version of the Window Server.

+
+ +

wserv_nonnga.exe

+

+

The non-ScreenPlay version of the Window Server.

+
+ +

ws32_nga.dll

+

ws32.lib

+

The Window Server client-side API library for the ScreenPlay variant. +See Window Server Client-Side +Library.

+
+ +

ws32_nonnga.dll

+

ws32.lib

+

The Window Server client-side API library for the non-ScreenPlay +variant. See Window +Server Client-Side Library.

+
+ +

wsgraphicdrawer_nga.dll

+

wsgraphicdrawer.lib

+

The server-side base classes for Window Server plug-ins in the ScreenPlay +variant. The plug-ins include graphic drawer plug-ins (which are also known +as Content Rendering Plug-ins or CRPs) and render stage plug-ins.

+
+ +

wsgraphicdrawer_nonnga.dll

+

wsgraphicdrawer.lib

+

The server-side base classes for Window Server plug-ins in the non-ScreenPlay +variant. The plug-ins include graphic drawer plug-ins (which are also known +as Content Rendering Plug-ins or CRPs) and render stage and fader plug-ins.

+
+ +

remotegc_nga.dll

+

remotegc.lib

+

The client-side API library for remote graphic contexts in ScreenPlay. +Remote graphic contexts store draw operations so that they can be played back +later. It is "remote" because the draw operations are generally played back +in a different location from where they are stored. For example, the draw +operations are frequently stored on the client side and then a transformation +engine uses them on the server side to make an effect.

+
+ +

remotegc_nonnga.dll

+

remotegc.lib

+

The client-side API library for remote graphic contexts in the non-ScreenPlay +variant. This has a similar role as in ScreenPlay.

+
+ +

profilerkeys.dll

+ +

Window Server profiling hotkeys library in both ScreenPlay and non-ScreenPlay +variants.

+
+ + +

Logging libraries

+ + + +Executable +Description + + + + +

dlog.dll

+

On-screen logging library

+
+ +

dlogfl.dll

+

File logging library

+
+ +

dlogrd.dll

+ +
+ +

dlogsr.dll

+

Serial logging library

+
+ + +

Plug-ins

+ + + +Executable +Variant +Description + + + + +

10281922.dll

+

Both

+

This is a standard reference CRP. This type of plug-in is called +a CWsGraphics ECOM plug-in. Device creators can replace this component.

+
+ +

2001b70b.dll

+

Non-ScreenPlay

+

This is a prototype reference render stage ECOM plug-in for the +non-ScreenPlay variant. This type of plug-in is called a CWsPlugin.

Note: +The ScreenPlay render stage ECOM plug-in is delivered in the Window Server +Plugins component.

+
+ +

10285c4a.dll

+

ScreenPlay

+

This is a reference ScreenPlay surface-based CRP. Device creators +can replace this component.

+
+ +

samplegraphicsurface.dll

+

ScreenPlay

+

Sample ScreenPlay CRP (CWsGraphics) that demonstrates placing +a surface.

+
+ +

w32stdgraphic.dll

+

Both

+

Sample CRP (CWsGraphics).

+
+ + +
+
Typical uses
    +
  • Application developers +use the client-side +library to control windows in their applications and respond to key +and pointer events.

  • +
  • Testers and application +developers use the logging +mechanism to log Window Server events when developing and testing their +code.

  • +
  • Device creators create +Content Rendering Plug-ins (CRPs) for showing customized content on the screen.

  • +
  • Device creators who +use ScreenPlay, can create render stage plug-ins. These enable the output +of the Window Server to be combined with auxiliary software subsystems (such +as a transition effect engine) and hardware-accelerated drawing (for example, +using OpenVG).

  • +
  • Device creators use +the wsini.ini file to +configure the Window Server to suit the specific requirements of the particular +device.

  • +
+
+Window Server +Component + + +
\ No newline at end of file