diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-7C75642D-C0C9-5392-9354-711F42DC2C61.dita
--- a/Symbian3/SDK/Source/GUID-7C75642D-C0C9-5392-9354-711F42DC2C61.dita Fri Jul 16 17:23:46 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-7C75642D-C0C9-5392-9354-711F42DC2C61.dita Tue Jul 20 12:00:49 2010 +0100
@@ -75,7 +75,7 @@
diagram demonstrates that typically the
A redrawer's
The "draw deferred" scenario
The "draw deferred" redraw scenario
is when an application simply marks a window or a rectangle within a window
as invalid. This eventually triggers a Window Server-initiated redraw. Typically
@@ -115,7 +115,7 @@
However, it is also possible to do this by calling
This approach is useful when the data to be displayed might be updated frequently but it is not necessary to update the display instantaneously.
To illustrate how it works, consider a window that has a rectangle that is used @@ -126,14 +126,14 @@ the following diagram.
However, if you use the "draw deferred" approach when each event occurs, the Window Server may not update the display for each one. For example, the Window Server does not update the display when it is superceded by a later call.
If it is important that the display is updated immediately, you would generally use the "draw now" approach. However, if a short delay in the display being updated is unlikely to inconvenience the user, the "draw