Initial contribution of the Adaptation Documentation.
<?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-7E401451-16EB-515B-88B2-4D0D2D6C7A57" xml:lang="en"><title>Adjustable
Performance Configuration</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>Various system parameters may be modified to control the way that elements
within the system behave. The parameters listed in this document have been
found to have significant impacts on important aspects of system performance. </p>
<p>In each case there is trade off, typically between speed and resource use
but sometimes between boot time and performance in steady state. The amount
of trade off varies according hardware, software and how both are used. The
only way of establishing the effect of each setting on a working device is
through systematic testing. </p>
<p>There is no common method of configuring the parameters listed here. Some
of the values must be set before compilation, others before the ROM is built. </p>
<ul>
<li id="GUID-EE04CF03-F56D-52D7-BFF4-3D3AAB7C6106"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-09C25275-5D3A-514B-8F0D-C5C1A3FA41EC">Bitmaps</xref> </p> </li>
<li id="GUID-02A6FF27-4E28-50F5-B0B7-C4BB20201FFE"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-6F89A67C-D05C-535B-B316-22EBECA7D7BF">Central Repository</xref> </p> </li>
<li id="GUID-17BCAC94-0678-5048-A33F-151B36E0E83D"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-F0EB9A69-C00B-5778-AB90-E8C78CF0E2CB">Comms Server</xref> </p> </li>
<li id="GUID-59149610-A605-5C6C-BA53-E921E2658D6C"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-4E07079A-B7B7-5020-BB15-8F31D5FAFCDA">Database Management System (DBMS)</xref> </p> </li>
<li id="GUID-31BBAE9F-7427-5925-9FE7-907EC852C366"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-0E06EE19-F1FE-5940-8167-34654BFBA90A">Domain Name Daemon</xref> </p> </li>
<li id="GUID-252ED29A-8F5A-54F2-A98C-65F48D080C61"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-BE38584C-7999-5D27-B4A2-1A7CFA82D311">Heap Configuration</xref> </p> </li>
<li id="GUID-F6E88149-0B78-5E48-8399-51268803591F"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-9F765460-7F6A-5F2A-85DE-89EBFE213B1E">Recognizer Loading</xref> </p> </li>
<li id="GUID-E5B09C3D-FF56-5D3B-B47A-B2D4EE265A86"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-9B98E4EB-28BC-5A0A-8174-7949E515AFA6">Secure Backup </xref> </p> </li>
<li id="GUID-A49DD8FE-958E-542F-98EF-7926A2A10722"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-4EC82389-6C89-5C47-BAC4-A139BCB3531E">Server shutdown behaviour</xref> </p> </li>
<li id="GUID-E792C035-38A4-561C-91CF-A23574E3E744"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-2CACB838-2E72-5723-9511-68EC1D7E3BDD">Window Server</xref> </p> </li>
</ul>
<section id="GUID-09C25275-5D3A-514B-8F0D-C5C1A3FA41EC"><title>Bitmaps</title> <p>Bitmaps
use up large amounts of memory. There are several parameters that you can
configure to reduce the amount of memory that bitmaps use. The effects that
your adjustments have will depend upon both the nature of the bitmaps used
in your system and the way that they are used. </p> <p><b>Bitmap compression ratio configuration </b> </p> <p>Bitmaps can be compressed
using algorithms that typically take advantage of blocks of common colour.
The amount that a bitmap can be compressed depends on the bitmap itself. </p> <p>A
bitmap stored in a compressed format has to be decompressed before it can
be displayed. </p> <p>A <b>compile-time macro</b>, <codeph>KCompressionThreshold</codeph>,
specifies how much reduction in size must be achievable for bitmaps to be
compressed. The theory is that if compression would only result in a small
difference in size it is a waste of time. </p> <dl>
<dlentry>
<dt>Location</dt>
<dd><p> <filepath>...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP</filepath> </p> </dd>
</dlentry>
<dlentry>
<dt>Source</dt>
<dd><codeblock id="GUID-BD267125-B08B-5723-9C4F-2737882BFD1D" xml:space="preserve">/*
KCompressionThreshold is used to determine whether a bitmap gets compressed.
Values of 0 -> 256 represent 0% to 100% where 0% = no compression.
A value of 205 means that bitmaps are only compressed when the resulting size is 80% or less
of the original size.
*/
MACRO KCompressionThreshold=205 // i.e. 80% compression
</codeblock> </dd>
</dlentry>
</dl> <p>You must recompile FBServ for this change to take effect. </p> <p><b>Bitmap storage location </b> </p> <p>Bitmaps are stored in different memory
locations according to their size. </p> <ul>
<li id="GUID-08722693-3C5C-50FD-BD60-EBE2C3EC28A3"><p>Small bitmaps are stored
in a normal heap called a shared chunk. </p> </li>
<li id="GUID-9066CCC7-4872-5BEC-B754-3406E02CE234"><p>Large bitmaps are stored
in special area of memory, called the large chunk or pile, that is managed
by the font and bitmap server. </p> </li>
</ul> <p>This is because storing and deleting bitmaps, especially large ones,
leads to memory fragmentation which can prevent RAM being freed for the rest
of the system. Defragmetation, however, is a slow process, so only the large
chunk is defragmented. </p> <p>A <b>compile-time macro</b>, <codeph>KMaxLargeBitmapAlloc</codeph>,
specifies the cut-off point (in kB) at which a bitmap is considered large
and, therefore, stored in the large chunk. </p> <p>The higher the value the
larger the bitmaps stored in the shared chunk will be. This typically results
in higher RAM use, because the heap becomes more fragmented, but better overall
system performance because the defragmentation process runs less often on
the large chunk. </p> <dl>
<dlentry>
<dt>Location</dt>
<dd><p> <filepath>...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP</filepath> </p> </dd>
</dlentry>
<dlentry>
<dt>Source</dt>
<dd><codeblock id="GUID-3EDA0707-66CD-563C-AB11-3FB72582CECB" xml:space="preserve">/*
configurable value to control bitmap heap defragmentation by setting large bitmap threshold
*/
MACRO KMaxLargeBitmapAlloc=0x4000
</codeblock> </dd>
</dlentry>
</dl> <p>You must recompile FBServ for this change to take effect. </p> <p><b>Large chunk defragmentation </b> </p> <p>Deleting large bitmaps results
in fragmentation of the large chunk (see above). </p> <p>A <b>compile-time
macro</b>, <codeph>KFreeCellCountLimit</codeph>, specifies the number of free
cells that must exist in the large chunk before it gets defragmented. </p> <dl>
<dlentry>
<dt>Location</dt>
<dd><p> <filepath>...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP</filepath> </p> </dd>
</dlentry>
<dlentry>
<dt>Source</dt>
<dd><codeblock id="GUID-576D18C1-6D4F-5E39-A69D-481D29F69CEE" xml:space="preserve">/*
KFreeCellCountLimit determines when a forced foreground defragmentation will take place.
This will happen during an allocation on the FBS large bitmap chunk if the amount
of free cells exceeds the specified number.
*/
MACRO KFreeCellCountLimit=40
</codeblock> </dd>
</dlentry>
</dl> <p>A smaller value will result in less wasted RAM but poorer performance
as the defragmentation process will run more often. </p> <p> <b>NOTE:</b> Cells
can be of variable size so this value cannot be used to calculate the amount
of wasted RAM. You can be sure, however, that the wasted RAM will be at least
(<codeph>KMaxLargeBitmapAlloc</codeph> x <codeph>KFreeCellCountLimit</codeph>).
For the default values this is 160kB. </p> <p>You must recompile FBServ for
this change to take effect. </p> <p><b>Using bitmap fonts </b> </p> <p>Using bitmap fonts instead of FreeType
fonts can reduce RAM use and increase performance at the expense of visual
appearance. FreeType fonts have to be rasterised before they can be used.
This takes time and memory. Bitmap fonts, however, can only be used in the
pre-determined range of sizes built into the ROM. </p> <p>The performance
trade off is dependant on the font rasteriser though once a font has been
rasterised it can be cached in bitmap form. </p> <p>NOTE: You can be pre-rasterise
FreeType fonts into bitmap fonts for inclusion in ROMs using the <codeph>ttf2bdf</codeph> tool.
Though the tool is supplied with the Symbian platform (as part of the <codeph>graphics_font</codeph> CBR
component) it is not supported. There may also be legal and licencing issues
to consider when pre-rasterising ronts in this way. </p> </section>
<section id="GUID-6F89A67C-D05C-535B-B316-22EBECA7D7BF"><title>Central Repository </title> <p>The
Central Repository caches individual repositories in RAM after clients have
closed their sessions. You can configure the <i>sizeof the cache</i> and the <i>length
of time that entries persist</i> by editing the central repository INI file <filepath>\private\10202be9\centrep.ini</filepath> </p> <codeblock id="GUID-D09B03B5-A74B-5EF5-B962-46756E491C48" xml:space="preserve">[CoarseGrainedCache]
size= <size in bytes>
timeout= <timeout in microseconds> </codeblock> <p>Increasing the size
of the cache and the timeout improve performance at the cost of increased
RAM use. </p> <p> <b>NOTE:</b> If the cache fills up the oldest entries are
pushed out before they timeout. </p> </section>
<section id="GUID-F0EB9A69-C00B-5778-AB90-E8C78CF0E2CB"><title>Comms Server</title> <p>You
can adjust the size of the <codeph>MBuf</codeph> pool. The <codeph>MBuf</codeph> pool
is used for creating buffers for communication data. </p> <p>The value is
set in <filepath>...\os\commsfw\commsprocess\commsrootserverconfig\etc\c32start.ini</filepath>. </p> <codeblock id="GUID-77C0F002-8BA1-5D2E-9EC6-78098940D30D" xml:space="preserve">
[Global]
MBufPoolSize=<initial size in bytes>,<max size in bytes> //The default is MBufPoolSize=262144,262144. </codeblock> <p> <b>NOTE:</b> In
older versions of the Symbian platform only the maximum size was specified
so, for compatibility reasons, if a single value is specified it will be interpreted
as the maximum size. </p> <p>When an initial size is specified the pool grows
as necessary until it reaches the maximum size. It does not shrink, however,
so the RAM is not released until the device is rebooted. The disadvantage
of setting a very low initial pool size is that there might be insufficient
free RAM pages when it tries to grow which could cause panics. </p> </section>
<section id="GUID-4E07079A-B7B7-5020-BB15-8F31D5FAFCDA"><title>Database Management
System (DBMS)</title> <p>The size of the <b>cache</b> used by DBMS and the
size of the <b>buffer</b> used by STORE when performing disk I/O are adjustable.
Reducing their sizes reduces memory use but results in more I/O operations
which reduces performance. </p> <p>Adjust the sizes of the cache and buffer
as follows: </p> <ol id="GUID-9021FD5C-01F7-575A-9B3B-DC7289266602">
<li id="GUID-EA542EA4-975D-5075-AD6D-46E09B37CCBA"><p>Define the constants <codeph>SYMBIAN_CUSTOM_DBMS_CACHE_SIZES</codeph> and <codeph>SYMBIAN_CUSTOM_STORE_BUFFER_SIZES</codeph> in the appropriate HRH file in <filepath>\epoc32\include\variant</filepath>. </p> </li>
<li id="GUID-2AA8EE9F-EDAD-515D-8407-8D4736A6CF15"><p>Create <filepath>...\os\persistentdata\persistentstorage\dbms\bmake\EDbms.mmh</filepath> by
copying <filepath>...\os\persistentdata\persistentstorage\dbms\bmake\EDbms_Template.mmh</filepath>. </p> <p>Edit
the newly created file and modify the following macros: </p> <ul>
<li id="GUID-00DE06B9-95F2-5DCB-A63E-1586CAE2686E"><p> <codeph>PAGE_CACHE_SIZE</codeph> -
the size of the page cache used to cache index information in a database.
It must not be less than 8 pages. </p> </li>
<li id="GUID-2182B6CC-F0CF-52F8-9986-231546A90D8C"><p> <codeph>MAX_CLUSTER_CACHE_SIZE</codeph> -
the size of the cluster cache which is used to cache row data for tables in
a database. It must not be less than 4 clusters. </p> </li>
</ul> </li>
<li id="GUID-E3FC7916-96B7-53F1-8E57-53243FFDAB78"><p>Create <filepath>...\os\persistentdata\persistentstorage\store\BMAKEEStor.mmh</filepath> by
copying <filepath>...\os\persistentdata\persistentstorage\store\BMAKE\EStor_Template.mmh</filepath>. </p> <p>Edit
the newly created file and modify the following macros: </p> <ul>
<li id="GUID-5D98A6F3-160F-5348-B85D-97E387E8AE70"><p> <codeph>DEFAULT_FILE_BUF_SIZE</codeph> This
macro sets the default file buffer size in bytes used in <xref href="GUID-418E7956-BE91-39A2-A26D-F1CA88B458AA.dita"><apiname>RFileBuf</apiname></xref> objects.
It must not be less than 1536 bytes. </p> </li>
<li id="GUID-A6CAC043-CC3E-519F-84DB-D1F9E6AB8C42"><p> <codeph>MAX_READ_AHEAD_VALUE</codeph> This
macro sets the maximum <xref href="GUID-418E7956-BE91-39A2-A26D-F1CA88B458AA.dita"><apiname>RFileBuf</apiname></xref> read-ahead value in bytes.
This defines the number of bytes read into the file buffer when buffer underflow
occurs. It must not be less than 512 bytes or greater than <codeph>DEFAULT_FILE_BUF_SIZE</codeph> </p> </li>
<li id="GUID-25FC3F98-0B4A-52E2-BF26-EDAEA0B03585"><p> <codeph>FILE_BLOCK_SIZE</codeph> This
macro sets the file-system block size for <xref href="GUID-418E7956-BE91-39A2-A26D-F1CA88B458AA.dita"><apiname>RFileBuf</apiname></xref>. It
is used in the event of a buffer underflow to perform block-aligned reads
to load the buffer. It must not be less than 512 bytes or greater then <codeph>MAX_READ_AHEAD_VALUE</codeph>.
It must also be a power of 2 </p> </li>
</ul> </li>
<li id="GUID-F7304DF3-99B5-50E5-8FA0-025A1C26317D"><p>Rebuild STORE then DBMS. </p> </li>
</ol> </section>
<section id="GUID-0E06EE19-F1FE-5940-8167-34654BFBA90A"><title>Domain Name
Daemon</title> <p>You can control the number of concurrent requests handled
by the Domain Name Daemon (DND). The DND reserves memory for these at startup
to guarantee service. Reducing the number saves RAM but slows down web page
retrieval, especially on pages with lots of in-line images. </p> <p>In the
file <filepath>...\os\networkingsrv\tcpiputils\dnd\inc\listener.h</filepath> </p> <codeblock id="GUID-3DFE4664-CAC8-5FE0-8D25-00D14D8754B3" xml:space="preserve">const TUint KDndNumResolver = 31 ;</codeblock> <p>You
can also limit the number of Link-Local Multicast Name Resolvers (LLNMR) that
get created which also saves RAM but impacts performance because fewer concurrent
DNS queries can be made </p> <p>In the file </p><filepath>...\os\networkingsrv\tcpiputils\dnd\inc\llmnrresponder.h</filepath> <codeblock id="GUID-E42FFFD4-2A9A-5D20-8171-F09AED1FEA15" xml:space="preserve">const TInt KLlmnrMaxEnabled = 15 ; </codeblock> <p> <b>NOTE:</b> You
must ensure that there is at least one resolver enabled for each LLMNR-enabled
network interface (NIF). </p> </section>
<section id="GUID-BE38584C-7999-5D27-B4A2-1A7CFA82D311"><title>Heap Configuration</title> <p><b>Minimum heap cell size </b> </p> <p>You can set the minimum heap cell
size used by the <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref> class. This has an impact on where
new allocations are placed in the heap. You can set values for both the kernel
heap and the user heap. </p> <p>The effect of changing the value is difficult
to predict and there is not a simple relationship between size and RAM use
or size and performance. In general, however, a larger value will result in
faster performance and greater RAM use. </p> <p>Typical values to experiment
with are 0, 4, 8, 16, 32 and 64. </p> <p>You set the value using a <codeph>patchdata</codeph> statement
in an OBY (or IBY) file. </p> <codeblock id="GUID-76A70134-04D6-57B1-8F1D-7C7BF7813B3B" xml:space="preserve">
patchdata [ekern.exe|euser.dll] @ KHeapMinCellSize <NewValueForTheConstData>
</codeblock> <p>For example </p> <codeblock id="GUID-34B89B58-109B-5DFF-A91F-D1C50866CE54" xml:space="preserve">
patchdata ekern.exe @ KHeapMinCellSize 32
patchdata euser.dll @ KHeapMinCellSize 32
</codeblock> <p><b>Hysteresis window size </b> </p> <p>You can configure how the memory allocated
by the <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref> class is returned to the system. </p> <p>The
heap grows in fixed size chunks. You can specify how quickly it shrinks (the
amount of hysteresis) by setting <codeph>KHeapShrinkHysRatio</codeph>. </p> <p>The
value of <codeph>KHeapShrinkHysRatio</codeph> is multiplied with the size
of the growth chunk to establish the hysteresis value. When heap cells are
freed the system waits until the number of free cells reaches the hysteresis
value before releasing the memory. </p> <p>The default value of <codeph>KHeapShrinkHysRatio</codeph> is
2.0. Reducing the value towards 1 frees memory more quickly. Values of 1 or
less result in no hysteresis. More hysteresis results in faster performance,
as heap allocations occur less often, but more RAM use. </p> <p>You set the
value using a <codeph>patchdata</codeph> statement in an OBY (or IBY) file.
For example, </p> <codeblock id="GUID-FE3EAA41-A9EE-5659-A57F-6186AE22BF65" xml:space="preserve">
patchdata ekern.exe @ KHeapShrinkHysRatio 1.5
patchdata euser.dll @ KHeapShrinkHysRatio 1.5
</codeblock> </section>
<section id="GUID-9F765460-7F6A-5F2A-85DE-89EBFE213B1E"><title>Recognizer
Loading</title> <p>You can configure the Apparc server to load recognizer
plugins at startup or on demand. Loading on demand reduces RAM consumption
and boot time. The trade-off is that the first use of each recognizer takes
longer to complete as it needs to be loaded before it can be used. Because
recognizers typically get used several times in quick succession the impact
of the trade off can be reduced by using a timer to defer unloading </p> <p>You
can enable or disable load-on-demand and specify the delay before unloading
using the <codeph>patchdata</codeph> statement in an OBY (or IBY) file. </p> <codeblock id="GUID-17741E7B-5EF8-52F9-9DED-C5482B78EDEE" xml:space="preserve">patchdata apserv.dll @ KApaLoadDataRecognizersOnDemand <newvalue> </codeblock> <p>The
default <codeph>newvalue</codeph> is 0 which means that recognizers are loaded
at boot. A value of 1 specifies that recognizers will be loaded on demand. </p> <codeblock id="GUID-D398EA48-F84C-528D-B0B1-40B8A8E6F1A1" xml:space="preserve">patchdata apserv.dll @ KApaUnloadRecognizersTimeout <newvalue> </codeblock> <p>The
default<codeph>newvalue</codeph> is 10000000 (10 seconds in milliseconds). </p> </section>
<section id="GUID-9B98E4EB-28BC-5A0A-8174-7949E515AFA6"><title>Secure Backup
Optimisation</title> <p>The secure backup engine uses a shared chunk to communicate
information efficiently between client and server components. You can set
the size of the chunk, and other parameters, in a file called <filepath>sbeconfig.xml</filepath> in
the private directory of the secure backup engine. The default size of the
chunk is 2MB. </p> <codeblock id="GUID-08DAB844-88CF-560B-93E0-718CBEA0A9C4" xml:space="preserve">
<?xml version="1.0" encoding="UTF-16" standalone="yes"?>
<sbe_config>
<heap size = "2097152" max_retries = "5" reduction_factor = "2"/>
<central_repository uid = "0x10202BE9"/>
<exclude_drives list = "z"/>
</sbe_config>
</codeblock> </section>
<section id="GUID-4EC82389-6C89-5C47-BAC4-A139BCB3531E"><title> Server shutdown
behaviour</title> <p>The shutdown behaviour of servers has a large impact
on RAM and performance characteristics. If a server is always running it can
respond faster to each request but requires RAM all the time. A transitive
server is one which shuts down when it has no active connections. A transitive
server uses RAM only when necessary but its performance will vary according
to whether it needs to be started. </p> <p>You can configure the shutdown
behaviour of several key Symbian servers. </p> <p><b>Message Server </b> </p> <p>Symbian provides two versions of the Message
Server: an always-on version and a transitive one. You can select which one
to include in your ROM by editing <filepath>../generic/messaging/framework/server/group/messageserver.iby</filepath> </p> <ul>
<li id="GUID-563A829D-7ED3-50E0-A90C-472D2EBEA65C"><p>For always-on include <filepath>msgs.dll</filepath> in
your ROM </p> </li>
<li id="GUID-42CD2F3D-9552-5FC7-910E-3B8D6EE8892C"><p>For transitive behaviour
include <filepath>msgs_autoshutdown.dll</filepath> in your ROM </p> </li>
</ul> <p><b>Contacts Server </b> </p> <p>The behaviour of the Contacts Server is determined
by a command line argument passed to <filepath>cntsrv.exe</filepath>. </p> <p>The
default behaviour is transitive. For always-on behaviour you must start the
server use the <codeph>-nontransient</codeph> option in your system startup
file. </p> <codeblock id="GUID-85079652-9D30-5B44-BCDF-8DB41759B2CC" xml:space="preserve">
START_PROCESS_INFO
{
path = "Z:\\sys\\bin\\cntsrv.exe";
args = "-nontransient";
...
}</codeblock> <p><b>Agenda Server </b> </p> <p>The behaviour of the Agenda Server is determined
by a command line argument passed to <filepath>agsvexe.exe</filepath>. </p> <p>The
default behaviour is transitive. For always-on behaviour you must start the
server use the <codeph>-nontransient</codeph> option in your system startup
file. </p> <codeblock id="GUID-DF1BBB3B-8A6E-5F63-B91C-9E4B9A952331" xml:space="preserve">
START_PROCESS_INFO
{
path = "Z:\\sys\\bin\\agsvexe.exe";
args = "-nontransient";
...
}</codeblock> </section>
<section id="GUID-2CACB838-2E72-5723-9511-68EC1D7E3BDD"><title>Window Server</title> <p><b>Flicker Free Redraw and Transparency </b> </p> <p>You can configure the
drawing behaviour of the window server by enabling or disabling support for<b>flicker
free redraw</b> and <b>transparency</b>. </p> <p>The window server is generally
configured to allocate two full-screen bitmaps (which consume over 140kB each
on a device with a normal resolution display). </p> <ul>
<li id="GUID-E42668D2-7D67-527A-9A4A-A84A58781701"><p>An off-screen bitmap
to reduce redraw flicker. Drawing commands between <codeph>BeginRedraw</codeph> and <codeph>EndRedraw</codeph> commands
are committed to the off-screen bitmap. Only when <codeph>EndRedraw</codeph> is
called does the window server update the screen with the contents of the off-screen
bitmap. </p> </li>
<li id="GUID-E4334927-57C3-5A1B-A6EF-549AFD203429"><p>A transparency bitmap
to support transparent windows. </p> </li>
</ul> <p>The allocation of these bitmaps can be configured in <filepath>Wsini.ini</filepath>. </p> <ul>
<li id="GUID-B529F499-7FCC-5076-859C-3D0ABF8E0B9B"><p>The presence of the
keyword <codeph>FLICKERFREEREDRAW</codeph> causes the off-screen bitmap to
be allocated. </p> </li>
<li id="GUID-751FB913-C942-5F8D-9A36-0B2727941977"><p>The presence of the
keyword <codeph>TRANSPARENCY</codeph> causes <b>both</b> the off-screen and
transparency bitmaps to be allocated. </p> </li>
<li id="GUID-7D32B174-8E33-5292-9096-3EF0EB825C60"><p>If neither keyword is
present no full-screen bitmaps are allocated. </p> </li>
</ul> <p> </p> <p>In practice flicker free redraw makes a noticeable improvement
to most UIs. If a UI uses transparent windows both bitmaps must be enabled. </p> <p><b>The default window server command buffer </b> </p> <p>Each connection
to the window server has a command buffer so that the number of inter-process
calls can be reduced. The buffer has a default size (<codeph>EClientBufferSize</codeph>)
which is typically the minimum of 640 bytes. Applications can override the
default whenever they create an <codeph>RWsSession</codeph>. </p> <p>The default
buffer size is defined in <filepath>...\os\graphics\windowing\windowserver\SERVER\w32cmd.h</filepath> </p> <p>The
benefit of a small buffer is reduced RAM use. The benefits of a bigger buffer
are reduced IPC (so drawing is more efficient) and reduced flicker. </p> <p> <b>NOTE:</b> Increasing
the buffer size to reduce flicker is less effective than using the <codeph>FICKERFREEREDRAW</codeph> feature
described above. </p> </section>
</conbody></concept>