<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-0AD34BA6-D0C5-5AD7-B8E1-F737BB5FC0AC" xml:lang="en"><title>Redraw

Stores</title><shortdesc>Redraw stores store the sequence of drawing commands representing

window contents. Whenever possible, the Window Server performs server-initiated

redraws by repeating the sequence of stored commands, rather than by sending

redraw requests to the client. This minimises the number of client-server

transactions and means that redraws are done as soon as the server detects

that they are needed. This topic explains some of the background to redraw

stores. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p> <b>Variant</b>: Both (ScreenPlay and non-ScreenPlay). <b>Target audience</b>:

Device creators. </p>

<p>The classes involved with redraw stores are as follows: </p>

<fig id="GUID-85C23EC3-BADE-5DE1-872D-0D8399209874">

<title>           Redraw stores class diagram          </title>

</fig>

<p> <xref href="GUID-FF963788-695A-320F-9E81-76E45B0287D1.dita"><apiname>CWsRedrawMsgWindow</apiname></xref> is the class representing a redraw

store. Draw commands are stored in a number of segments, stored in the nested

class <xref href="GUID-53F68722-1A1D-30D8-960E-226843AB56E1.dita"><apiname>CRedrawSegment</apiname></xref>. </p>

<p>Redraw drawing takes place as follows: </p>

<ol id="GUID-2C26C7D9-1C38-55E1-BF14-A36A9F9F05F3">

<li id="GUID-2FCE8CBF-6BF3-5033-8BB7-935D0B276F7C"><p>A call to <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> causes

either the whole window, or a rectangle within it, to be marked as invalid. </p> </li>

<li id="GUID-EB4CAD7F-1B3C-5D2A-85FD-31D0C7F9503D"><p>Next, a call to <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita#GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79/GUID-9337538E-7A53-3153-A330-968B5E4F2FF2"><apiname>RWindow::BeginRedraw()</apiname></xref> is

made, either for the whole window or for a rectangle within it. </p> </li>

<li id="GUID-88AF657A-8C5E-5CE8-BEF9-F8C1E34F6174"><p>Draw operations take

place. </p> </li>

<li id="GUID-58BC4A48-5035-582D-BE17-C15A885F4B5F"><p>Finally there is a call

to <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita#GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79/GUID-3DE16607-AD3B-3946-BEB3-88512EAAB9CE"><apiname>RWindow::EndRedraw()</apiname></xref>. </p> </li>

</ol>

<p>In this sequence, the draw operations within the <codeph>BeginRedraw()</codeph> and <codeph>EndRedraw()</codeph> brackets

are interpreted as <i>replacing</i> whatever drawing was previously present

in the affected rectangle. </p>

<p>It is important to bracket all drawing within <codeph>BeginRedraw(TRect)</codeph> and <codeph>EndRedraw(TRect)</codeph> calls.

In ScreenPlay, the Window Server ignores all drawing not within <codeph>BeginRedraw()</codeph> and <codeph>EndRedraw()</codeph> brackets

and triggers a full-window redraw. In debug builds, there is an option to

panic clients violating this convention. </p>

<p>For more information, see <xref href="GUID-8DB1C618-597C-560C-95A2-C0AB2CEBB027.dita">Redraw

Drawing</xref>. </p>

<section id="GUID-27FE041D-3DE3-4290-AF6D-38DDB8970008"><title>Redraw segments and non-redraw handling</title> <p>When the

Window Server receives a batch of redraw drawing, everything between a BeginRedraw/EndRedraw

bracket is stored in a single <b>redraw segment</b>. The segment is marked

as <codeph>ESegmentTypePendingRedraw</codeph> while it is being received,

and <codeph>ESegmentTypeRedraw</codeph> once it is complete. </p> <p>Redraw

segments have a region to which they apply. For <codeph>ESegmentTypeRedraw</codeph>,

the region is initially set to be the rectangle passed into the <codeph>BeginRedraw()</codeph> call.

When a new<codeph>ESegmentTypeRedraw</codeph> is created, its region is subtracted

from the regions of all existing segments. This reflects the fact that redraw

drawing <i>replaces</i> existing drawing. If, as a consequence of new redraw

drawing, the region of an existing segment becomes empty, that segment is

discarded. Its drawing has been replaced everywhere, so it is no longer needed. </p> <p>What

happens to drawing that is received between an <codeph>EndRedraw</codeph> and

the next <codeph>BeginRedraw</codeph> —and which is therefore <b>non-redraw

drawing</b> —depends on which variant is in use: </p> <ul>

<li id="GUID-0B29AC2F-AD48-5EAB-B3BE-B8FC296B092A"><p>In ScreenPlay, non-redraw

drawing is not stored in a segment but instead triggers the Window Server

to invalidate the entire window. This means that the client application must

then perform a full window redraw. </p> </li>

<li id="GUID-B592A6D0-68B7-5A16-B179-9F78C5FCDBB3"><p>In the non-ScreenPlay

variant, non-redraw drawing is stored in a segment marked as <codeph>ESegmentTypeNonRedraw</codeph>.

For these segments the region is initially set to be the whole window and

does not affect the regions of existing segments, because non-redraw drawing

is drawn over existing drawing. </p> </li>

</ul> </section>

<section id="GUID-DB24B91E-6628-4B6E-AE9A-ACAB30AA02C3"><title> Redraw store playback</title> <p>When playback is required,

the redraw store goes through the redraw segments and replays them if the

region for the segment intersects the region that is to be redrawn. It follows

from the way that they are managed that the regions of redraw segments are

mutually disjoint. This means that in ScreenPlay they can be replayed in any

order. This is also true in the non-ScreenPlay when there are only redraw

segments present. </p> <p>In the non-ScreenPlay variant, any non-redraw segments

are replayed in earliest-first order, because they draw on top of earlier

drawing. </p> </section>

<section id="GUID-74EC09C2-BB39-42B2-B765-191A7E17A4D6"><title> Aging of non-redraw segments</title> <p> <b>Variant</b>:

Non-ScreenPlay only. </p> <p>Non-redraw segments can cause inefficient operation

of redraw stores. For this reason, in the non-ScreenPlay variant where non-redraw

segments are still used, the Window Server "ages" them. That is, non-redraw

segments are considered to have a finite lifetime, after which they are discarded.

When a non-redraw segment is discarded, the Window Server makes a redraw request

to the client asking it to provide new draw operations for the invalid region. </p> <p>The

lifetime for non-redraw segments is set in the <xref href="GUID-1D529BDC-6665-58E2-AB3F-7023D8A84F69.dita">WSINI.INI

file</xref> using the parameter <codeph>NONREDRAWAGELIMIT</codeph>, followed

by a duration in microseconds. If this line is not present in the <codeph>WSINI.INI</codeph>,

a default of one second is used. </p> </section>

<section id="GUID-8CE71B67-21F3-4D16-9A1A-70A70A24EFD3"><title>Atomic Redraws</title> <p> <b>Variant</b>: Both (ScreenPlay

and non-ScreenPlay). </p> <p>Another <xref href="GUID-1D529BDC-6665-58E2-AB3F-7023D8A84F69.dita">WSINI.INI

file</xref> setting that affects redraw storing is <codeph>ATOMICREDRAWS</codeph>.

If this parameter is present, new draw operations received after a <codeph>BeginRedraw()</codeph> are

not considered valid until the corresponding <codeph>EndRedraw()</codeph> is

received. In particular, a new segment does not replace existing segments

until it is complete. This has the consequence that if redraw store playback

is required before the <codeph>EndRedraw()</codeph> for a new segment is received,

draw operations from old segments for that region are used instead. Thus drawing

within <codeph>Begin/EndRedraw</codeph> brackets can be considered as an atomic

operation. This eliminates one potential source of flicker. </p> </section>

</conbody><related-links>

<link href="GUID-484B51EC-2209-5492-8E9C-9D792AB0DF35.dita"><linktext>Graphics

and Drawing </linktext></link>

<link href="GUID-1D529BDC-6665-58E2-AB3F-7023D8A84F69.dita"><linktext>The wsini.ini

File Reference</linktext></link>

</related-links></concept>