--- a/Symbian3/PDK/Source/GUID-2BF409EA-82BF-407C-B048-DA0973B7F61D.dita	Tue Mar 30 11:42:04 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-2BF409EA-82BF-407C-B048-DA0973B7F61D.dita	Tue Mar 30 11:56:28 2010 +0100
@@ -1,35 +1,35 @@
-<?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-2BF409EA-82BF-407C-B048-DA0973B7F61D" xml:lang="en"><title>Optimizing
-feedback latency</title><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>The general latency requirement for touch feedback is 30 milliseconds.
-For direct feedback it is not always possible to achieve this, as in high
-CPU load cases it may take more than 30 ms already before the pointer event
-reaches the application. </p>
-<p>However, you can also affect the latency in your application: the maximum
-additional latency for direct feedback is as long as it takes for the longest
-running <codeph>RunL</codeph> of any active object running in application’s
-thread to execute. Hence keeping all <codeph>RunL</codeph> functions short
-improves the feedback latency (and of course also improves the overall responsiveness
-of the application). </p>
-<p>Another way of improving the latency is optimizing redrawing in such a
-way that only the necessary area of the screen is drawn. </p>
-<p>For example, if there are 20 buttons in the application and one of them
-is pressed down by a pointer event, then only that button should be redrawn
-and not the whole screen. This optimization improves both direct and area
-registry based feedback, because the window server cannot receive pointer
-events from the touch driver in case it is performing a draw operation, and
-unnecessarily massive draw operations can thus have significant effect on
-the latency.</p>
-<p>Finally, it is recommended that you trigger direct feedback in <codeph>HandlePointerEventL</codeph> as
-the first thing before doing any other processing, such as redrawing.</p>
+<?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-2BF409EA-82BF-407C-B048-DA0973B7F61D" xml:lang="en"><title>Optimizing
+feedback latency</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>The general latency requirement for touch feedback is 30 milliseconds.
+For direct feedback it is not always possible to achieve this, as in high
+CPU load cases it may take more than 30 ms already before the pointer event
+reaches the application. </p>
+<p>However, you can also affect the latency in your application: the maximum
+additional latency for direct feedback is as long as it takes for the longest
+running <codeph>RunL</codeph> of any active object running in application’s
+thread to execute. Hence keeping all <codeph>RunL</codeph> functions short
+improves the feedback latency (and of course also improves the overall responsiveness
+of the application). </p>
+<p>Another way of improving the latency is optimizing redrawing in such a
+way that only the necessary area of the screen is drawn. </p>
+<p>For example, if there are 20 buttons in the application and one of them
+is pressed down by a pointer event, then only that button should be redrawn
+and not the whole screen. This optimization improves both direct and area
+registry based feedback, because the window server cannot receive pointer
+events from the touch driver in case it is performing a draw operation, and
+unnecessarily massive draw operations can thus have significant effect on
+the latency.</p>
+<p>Finally, it is recommended that you trigger direct feedback in <codeph>HandlePointerEventL</codeph> as
+the first thing before doing any other processing, such as redrawing.</p>
 </conbody></concept>
\ No newline at end of file