diff -r ebc84c812384 -r 46218c8b8afa Symbian3/PDK/Source/GUID-E5CDDA05-CD86-5C44-B9DA-3249D9C14396.dita --- a/Symbian3/PDK/Source/GUID-E5CDDA05-CD86-5C44-B9DA-3249D9C14396.dita Thu Mar 11 15:24:26 2010 +0000 +++ b/Symbian3/PDK/Source/GUID-E5CDDA05-CD86-5C44-B9DA-3249D9C14396.dita Thu Mar 11 18:02:22 2010 +0000 @@ -1,104 +1,104 @@ - - - - - -Client-Side -BufferThe Window Server client-side buffer enables drawing functions -to be buffered and executed in sequence. This saves many client-server context -switches and makes the system fast and responsive. -

The Window Server handles many application function calls -as follows:

-
    -

  1. The client packages -the information to send to the server.

    2. -

  2. A context switch to -the server.

    3. -

  3. Processing in the Window -Server—with possible inter-thread communication to and from the client.

    4. -

  4. A context switch back -to the client.

    5. -
-

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

-

However, for 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 a command -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 is 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 minimize 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 may 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 optimizations.

-

If a message is too big for the buffer, a panic (#5 - EW32PanicDataExceedsBufferLength) -occurs. optimizations

- -Window Server -Client-Side Library Concepts + + + + + +Client-Side +BufferThe Window Server client-side buffer enables drawing functions +to be buffered and executed in sequence. This saves many client-server context +switches and makes the system fast and responsive. +

The Window Server handles many application function calls +as follows:

+
    +

  1. The client packages +the information to send to the server.

    2. +

  2. A context switch to +the server.

    3. +

  3. Processing in the Window +Server—with possible inter-thread communication to and from the client.

    4. +

  4. A context switch back +to the client.

    5. +
+

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

+

However, for drawing and many other function calls, this approach is too +slow, and is not strictly necessary.

+
    +

  • The overheads of the +client/server communication swamp the time needed for drawing and cause severe +system degradation.

    • +

  • It is unnecessary because +the client program does not need a result from drawing functions. This is +also true for some non-drawing functions.

    • +
+

Because of this, drawing functions, and other functions that do not need +a synchronous response, are buffered by the client interface in a command +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 full.

    • +

  • A function requiring +a result is called.

    • +

  • One of the event-request +functions is called (RWsSession::EventReady(), RWsSession::RedrawReady(), RWsSession::PriorityKeyReady()).

    • +

  • Certain high-level functions +are called by the client, such as CWindowGc::DrawPolyLine(), +which involve mass data transfer which would overflow the buffer, and which +may fail.

    • +

  • An explicit RWsSession::Flush() call +is made.

    • +

  • After any function call +if the RWsSession::SetAutoFlush() auto flushing function +is set on.

    • +
+

It is desirable that the buffer is 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:

+
    +

  • While debugging, client +requests do not immediately result in screen updates. This can make debugging +confusing at times.

    • +

  • If this is a problem, +the application program can turn on auto-flushing, which causes flushing after +each function call. The Uikon UI provides a hot-key, CTRL+ALT+SHIFT+F, to +turn on auto-flushing. (The resulting degradation in performance is a convincing +demonstration of the need for the buffer).

    • +

  • The GDI is so fast that +most drawing activity that takes place within the context of a single flush +appears as an almost instantaneous update. If, however, a drawing sequence +is interrupted by a flush, there may be a perceptible delay. In some circumstances, +this may result in flicker.

    • +

  • The aesthetics of a +program can be badly affected by flicker during drawing. Applications should +use flicker-free functions (such as DrawText() with a rectangle), +and try to minimize flushing during critical redraw sequences. If completely +flicker-free drawing is impossible, short drawing sequences that are flush-free +may sometimes be an acceptable alternative.

    • +
+

The Window Server manages the buffer intelligently so as to minimize 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 may 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 optimizations.

+

If a message is too big for the buffer, a panic (#5 - EW32PanicDataExceedsBufferLength) +occurs. optimizations

+ +Window Server +Client-Side Library Concepts \ No newline at end of file