The Window Server Rendering Loop

This 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.

Target audience: Device creators.

The following diagram provides a simplified representation of the upper and lower 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 AVKON and other legacy applications issue draw operations. For these applications, 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().

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 the redraw stores to be drawn to the UI surface and the updates to the window tree to be passed as a set of layers or scene elements to the composition engine. This is done through an additional level of indirection called render stages, which are replaceable plug-ins to the Window Server.

  Render stages were originally designed to enable customization of the final stages of the CWindowGc rendering pipeline. For Qt and Orbit applications, the primary role of the render stages is to perform transition effects (TFX) between applications (such as fading applications in and out). The Qt and Orbit framework provides the ability to perform TFX within the UI and other elements of a Qt application itself.

In dirty-rectangle tracking mode, 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 lower loop to run.

The lower loop passes the set of layers to the first render stage. In addition, for legacy applications the lower loop cleans 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.