Symbian
Symbian OS Library

SYMBIAN OS V9.3

[Index] [Spacer] [Previous] [Next]



Client-side buffer

The window server handles many application function calls in the following way:

  1. client interface packages the information for sending to server

  2. a context switch to the server

  3. processing in the window server - with possible inter-thread communication to and from the client

  4. a context switch back to the client

This guarantees that operations are performed in the right sequence, and that operations have been performed when control returns to the application program.

However, in the case of drawing and many other function calls, this approach is too slow, and is not strictly necessary.

Because of this, drawing functions, and other functions that do not need a synchronous response, are buffered by the client interface in an applications window server buffer. When necessary, this buffer is flushed by a call to the window server, which executes all the drawing functions in sequence. Thus, two context switches are sufficient for an entire buffer full of drawing requests.

The window server buffer is flushed when

It is desirable that the buffer be flushed when the application has finished a unit of drawing. This is usually done as a natural consequence of calling the function to wait for the next event from the window server. This covers all cases where drawing is initiated in response to a window server event. There are a few cases where drawing is initiated in response to other events: in these cases, an explicit Flush() call must be made.

The use of a buffer has two main impacts on drawing logic:

The window server manages the buffer intelligently so as to minimise flushing. The opcodes stored in the buffer are short, and repeated use of the same graphics context is indicated by a single bit rather than repeated reference to the graphics context.

Applications may modify the size, or the maximum size of the buffer to tune performance or to accommodate long messages. A larger buffer might reduce flicker by collecting more drawing commands. A smaller buffer uses less memory. Setting a maximum size allows the Window Server to perform its own optimisations.

If a message is too big for the buffer a panic (#5 - EW32PanicDataExceedsBufferLength) will occur.