Chapter 1

Figure 18.5
When the buffer is full, or when a function such as DrawPolyLine()(which requires largescale
data transfer) is invoked, the client interface 'flushes' the buffer – that is, it requests the
window server to execute all operations stored in the buffer. The window server reads the
buffer using an interthread read, and then executes all the drawing commands stored in it.
The buffer is reasonably large and its format has been optimized so that the above
commands and more would easily fit inside one buffer.
Note
Symbian has had two opportunities to see what happens if you don't do this
kind of client-side buffering. During early Symbian OS development, prior to
implementing the window server buffer, graphics were very slow. During the
Java implementation project, prior to implementing client-side buffering from
Java programs to the AWT server, a similar thing happened. You can see
the effects for yourself on the emulator by putting the window server client
interface into 'auto-flush' mode, which empties the buffer after each
command. Use Ctrl + Alt + Shift + F to turn on auto-flush, and Ctrl + Alt +
Shift + G to turn it off again. The difference is noticeable – and bear in mind
that your PC's clock is probably many times faster than that of a Symbian OS
phone.
Client-side buffering has some consequences in the API. First, the operations that are
buffered cannot return a result. Second, you sometimes need to be able to force a buffer
flush. With the window server, a Flush()function is available for this purpose. Flush() is
called by UIKON's active scheduler prior to waiting for the next request, so there are
relatively few circumstances in which you would need to call it yourself.
Note
The stream store also implements client-side buffering. A write stream uses
a buffer that is flushed to the destination file only when it is full, or when you
call RWriteStream::CommitL(). A read stream uses a buffer, which it
prefills from the source file and which it uses until another buffer of source
data is needed.
18.2.2 High-level Transactions
If the overheads of a transaction are high, then if possible you should specify the client API
so that one transaction does a lot of work.