--- 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 <xref href="GUID-12C281FF-546C-318D-8783-F26B0F619E11.dita"><apiname>RunL()</apiname></xref> starts with
a <xref href="GUID-C57CFECB-72CD-39EB-A83E-82A9E985F56B.dita"><apiname>GetRedraw()</apiname></xref> and ends with a call to <xref href="GUID-E3F0CB70-58E4-32FD-9828-71DF2F9976D3.dita"><apiname>RedrawReady()</apiname></xref>. </p> <fig id="GUID-B092D136-8C18-5237-A095-F8C3BBFFDDB4">
<title> Window Server-initiated redraw </title>
-<image href="GUID-0528A294-AC1B-5CDD-B59C-A105F39D748F_d0e190203_href.png" placement="inline"/>
+<image href="GUID-0528A294-AC1B-5CDD-B59C-A105F39D748F_d0e195174_href.png" placement="inline"/>
</fig> <p>A redrawer's <codeph>RunL()</codeph> function must <b>not</b> perform
any non-redraw drawing (that is, any drawing operations that are not bracketed
within the calls to <codeph>BeginRedraw()</codeph> and <codeph>EndRedraw()</codeph>).
@@ -107,7 +107,7 @@
</ol> <fig id="GUID-6E2637DC-F92A-56DE-BB07-F109F5CA681B">
<title> Application-initiated redrawing, "draw now" scenario
</title>
-<image href="GUID-4BC95F70-2F3F-5CFE-B057-0C5A97430573_d0e190311_href.png" placement="inline"/>
+<image href="GUID-4BC95F70-2F3F-5CFE-B057-0C5A97430573_d0e195282_href.png" placement="inline"/>
</fig> <p><b>The "draw deferred" scenario </b> </p> <p>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 <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita#GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79/GUID-28202F81-52FE-30F5-8B8C-ABED0915822E"><apiname>RWindow::Invalidate()</apiname></xref>. </p> <fig id="GUID-8B78CE09-EE92-50B3-8000-731BD9C20890">
<title> Application-initiated redrawing, "draw deferred" scenario
</title>
-<image href="GUID-21EF9E6F-A0BF-5EB2-9E3F-CA6A011D4C89_d0e190335_href.png" placement="inline"/>
+<image href="GUID-21EF9E6F-A0BF-5EB2-9E3F-CA6A011D4C89_d0e195306_href.png" placement="inline"/>
</fig> <p>This approach is useful when the data to be displayed might be updated
frequently but it is not necessary to update the display instantaneously. </p> <p>To
illustrate how it works, consider a window that has a rectangle that is used
@@ -126,14 +126,14 @@
the following diagram. </p> <fig id="GUID-04BCFA21-8D44-5FEA-BE29-57B40AC9CF99">
<title> Icons displayed using the "draw now" approach
</title>
-<image href="GUID-89185EBD-223F-5F52-B1CA-9F9692F7D21F_d0e190349_href.png" placement="inline"/>
+<image href="GUID-89185EBD-223F-5F52-B1CA-9F9692F7D21F_d0e195320_href.png" placement="inline"/>
</fig> <p>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. </p> <fig id="GUID-1E0E2A3C-1E63-58F6-940F-0D439FA6C721">
<title> Icons displayed using the "draw deferred" approach
</title>
-<image href="GUID-EDC405DC-F222-59CD-836E-180F8E1D2D11_d0e190360_href.png" placement="inline"/>
+<image href="GUID-EDC405DC-F222-59CD-836E-180F8E1D2D11_d0e195331_href.png" placement="inline"/>
</fig> <p>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