Window Server Component Overview
The 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.
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.
Omit the SYMBIAN_GRAPHICS_BUILD_OPENWF_WSERV macro shown above if you want to use the GCE-based components rather than the OpenWF-C-based components.
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.