<?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= &lt;timeout in microseconds&gt; </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=&lt;initial size in bytes&gt;,&lt;max size in bytes&gt; //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 &lt;newvalue&gt; </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 &lt;newvalue&gt; </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>