diff -r 51a74ef9ed63 -r ae94777fff8f Symbian3/SDK/Source/GUID-22093E74-EFE7-5642-93DE-1573E18F7C08.dita --- a/Symbian3/SDK/Source/GUID-22093E74-EFE7-5642-93DE-1573E18F7C08.dita Wed Mar 31 11:11:55 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-22093E74-EFE7-5642-93DE-1573E18F7C08.dita Fri Jun 11 12:39:03 2010 +0100 @@ -1,119 +1,119 @@ - - - - - -The -Window Server Rendering LoopThis topic provides a brief introduction to the Window Server's -rendering loop, which takes place in two stages, known as the upper loop and -the lower loop. -

Variant: ScreenPlay and non-ScreenPlay. Target -audience: Device creators.

-

The following diagram provides a simplified representation of the upper -and lower loops.

- -The Window Server's upper and lower rendering loops - - -

-

The upper loop is the process by which the Window Server’s scene -state information is updated based on commands from the client. There are -two types of scene state updates: window tree updates (such as when a window -is moved) and redraw store updates (such as when new drawing operations are -sent for a particular window).

-

The lower loop is the process by which updates are made to what -the user sees on the screen. The lower loop runs after the upper loop.

-

The two most important APIs on the client side are:

- - -The main participants in the ScreenPlay Window Server rendering loop - - -

On the client side, RWindow and CWindowGc commands -are converted to opcodes that are stored in a command buffer. When the command -buffer is full, it is automatically flushed, which means that it is -transferred across to a corresponding server-side command buffer. The client -can also explicitly request a flush using RWsSession::Flush().

-

On the server side:

- -

The details of the upper and lower loops vary depending on whether dirty-rectangle -tracking or change tracking is in use.

-

Dirty-rectangle tracking mode

-

Dirty-rectangle tracking mode is always used in the non-ScreenPlay variant -and is the default mode in ScreenPlay.

-

Updates to both the window tree and the redraw stores typically mean that -the current contents of the screen become invalid. Therefore, when processing RWindow or CWindowGc commands, -the upper loop adds the affected regions to a list of dirty rectangles that -need to be redrawn. The list includes transparent windows that are on top -of other windows and excludes windows that are obscured. The upper loop then -starts a scheduler, which eventually causes the dirty rectangles to be redrawn.

-

Some time later the scheduler runs the lower loop. The task of the lower -loop is to clean any dirty rectangles by playing (or replaying) the drawing -operations from the redraw stores into the first render stage. This is done -for all of the visible windows, starting at the back and working forwards.

-

Change tracking mode

-

Change tracking mode is only available in ScreenPlay. To enable change -tracking mode, add the CHANGETRACKING parameter to the wsini.ini file. This -parameter is set on a per-screen basis.

-

In change tracking mode, the upper loop keeps a list of all of the windows -for which there are new or changed drawing operations, regardless whether -the window is obscured or not. The list does not include transparent windows -that have not changed and which are on top of other windows. As in dirty-rectangle -tracking mode, changes cause the upper loop to start the scheduler which eventually -causes the lower loop to run. This plays the drawing operations for all of -the windows in the list of changed windows into the first render stage.

-

Typically you enable change tracking mode only if you are creating a transition -effects (TFX) render stage that is building up its own visuals stores. Visual -stores are replicas of the redraw stores and are often used with a visuals -tree. A visuals tree is a replica of the Window Server's window tree, into -which the render stage may add nodes that the Window Server does not "know" -about. In addition, these render stages typically introduce transition effects -which may change the visibility of windows that the Window Server does know -about. For example, the following diagram shows a transition effect in which -a window slides onto the screen from the top and temporarily obscures an existing -window on the screen.

- - A transition effect temporarily obscures a window on the screen - - -

In this and similar scenarios, the Window Server does not know whether -a window is obscured or visible. Therefore dirty-rectangle tracking is not -effective.

-

Each screen on the device has a separate render stage chain. -Because you set the CHANGETRACKING parameter on a per-screen -basis, it is possible to have a sophisticated TFX on one screen and a simple -display render stage on another screen.

- -Redraw Stores - -Window Server -Internals: Concepts - + + + + + +The +Window Server Rendering LoopThis topic provides a brief introduction to the Window Server's +rendering loop, which takes place in two stages, known as the upper loop and +the lower loop. +

Variant: ScreenPlay and non-ScreenPlay. Target +audience: Device creators.

+

The following diagram provides a simplified representation of the upper +and lower loops.

+ +The Window Server's upper and lower rendering loops + + +

+

The upper loop is the process by which the Window Server’s scene +state information is updated based on commands from the client. There are +two types of scene state updates: window tree updates (such as when a window +is moved) and redraw store updates (such as when new drawing operations are +sent for a particular window).

+

The lower loop is the process by which updates are made to what +the user sees on the screen. The lower loop runs after the upper loop.

+

The two most important APIs on the client side are:

+
    +

  • RWindow, +which is the class through which a client controls a window. Its main functions +enable a client to create and destroy windows, move and resize them, make +them visible or invisible, and send them to the foreground or background.

    • +

  • CWindowGc, +which is the class through which a client issues draw operations. At any given +time, a CWindowGc is activated on a particular window. The CWindowGc functions +that are used most frequently are DrawBitmap() and BitBlt(), +for drawing a skin bitmap as a background, and DrawText().

    • +
+ +The main participants in the ScreenPlay Window Server rendering loop + + +

On the client side, RWindow and CWindowGc commands +are converted to opcodes that are stored in a command buffer. When the command +buffer is full, it is automatically flushed, which means that it is +transferred across to a corresponding server-side command buffer. The client +can also explicitly request a flush using RWsSession::Flush().

+

On the server side:

+
    +

  • The upper loop processes +the server-side command buffers. RWindow commands are processed +as updates to the window tree. CWindowGc commands +are processed as updates to the redraw stores.

    • +

  • The lower loop ultimately +causes the updates to be drawn to the UI surface. However, the updates do +not go straight to the UI surface. Instead they go through an additional level +of indirection called render stages. These are replaceable plug-ins +to the Window Server, which enable the customization of the final stages of +the rendering pipeline.

    • +
+

The details of the upper and lower loops vary depending on whether dirty-rectangle +tracking or change tracking is in use.

+

Dirty-rectangle tracking mode

+

Dirty-rectangle tracking mode is always used in the non-ScreenPlay variant +and is the default mode in ScreenPlay.

+

Updates to both the window tree and the redraw stores typically mean that +the current contents of the screen become invalid. Therefore, when processing RWindow or CWindowGc commands, +the upper loop adds the affected regions to a list of dirty rectangles that +need to be redrawn. The list includes transparent windows that are on top +of other windows and excludes windows that are obscured. The upper loop then +starts a scheduler, which eventually causes the dirty rectangles to be redrawn.

+

Some time later the scheduler runs the lower loop. The task of the lower +loop is to clean any dirty rectangles by playing (or replaying) the drawing +operations from the redraw stores into the first render stage. This is done +for all of the visible windows, starting at the back and working forwards.

+

Change tracking mode

+

Change tracking mode is only available in ScreenPlay. To enable change +tracking mode, add the CHANGETRACKING parameter to the wsini.ini file. This +parameter is set on a per-screen basis.

+

In change tracking mode, the upper loop keeps a list of all of the windows +for which there are new or changed drawing operations, regardless whether +the window is obscured or not. The list does not include transparent windows +that have not changed and which are on top of other windows. As in dirty-rectangle +tracking mode, changes cause the upper loop to start the scheduler which eventually +causes the lower loop to run. This plays the drawing operations for all of +the windows in the list of changed windows into the first render stage.

+

Typically you enable change tracking mode only if you are creating a transition +effects (TFX) render stage that is building up its own visuals stores. Visual +stores are replicas of the redraw stores and are often used with a visuals +tree. A visuals tree is a replica of the Window Server's window tree, into +which the render stage may add nodes that the Window Server does not "know" +about. In addition, these render stages typically introduce transition effects +which may change the visibility of windows that the Window Server does know +about. For example, the following diagram shows a transition effect in which +a window slides onto the screen from the top and temporarily obscures an existing +window on the screen.

+ + A transition effect temporarily obscures a window on the screen + + +

In this and similar scenarios, the Window Server does not know whether +a window is obscured or visible. Therefore dirty-rectangle tracking is not +effective.

+

Each screen on the device has a separate render stage chain. +Because you set the CHANGETRACKING parameter on a per-screen +basis, it is possible to have a sophisticated TFX on one screen and a simple +display render stage on another screen.

+ +Redraw Stores + +Window Server +Internals: Concepts + \ No newline at end of file