Developers

Omnis Technical Note TNWE0006

The size of web forms and what is sent from the Server to the Client when opening the form for the first time

For Omnis Studio 2.4
By Rudolf Bargholz

This Technical note describes what data is sent from the Studio web application server to the browser client when the client requests a web form. It describes which data is sent to the browser and the size of each object sent. Based on this information one can optimize the size of the remote form which is loaded to the client.

Contents:
Summary
$classdata
Instance variables
Icon pages
Font tables #WIWFONTS
Style tables #STYLES
Background pictures
Control Download List
Other issues

Summary

When a remote form is accessed from a web browser, the Studio application server has to send remote form information from the server to the client. To optimise this process, it is important to know what exactly Studio sends to the client. Studio sends the following:

1. the remote form's $classdata less the code of the form
2. the instance variables as filled in the $construct or initialised using $initval
3. the iconpages assigned for the web form
4. the font table #WIWFONTS
5. the styles table #STYLES
6. any background pictures which were pasted into the web form
7. the control download list It is relatively simple to determine what each of these points
add to the total size of the remote form. Please see below for more information.

$classdata

Only the visible objects and their properties are sent to the browser as data. It is simple to determine the number of bytes required to send an empty form. Create a new web form without any code and open the remote form in the browser. The results shown below will be with Internet Explorer on Win2000. Open the notation inspector in Studio and have a look at the properties of the remote task instance under $iremotetasks. Here there is a property called $connectbytessent which tells one how much data was sent from the server to the browser. If one sends an empty form, the number of bytes sent to the client is 2197 bytes:

* Empty form - 244 bytes

If one now adds single objects to the remote form and opens the remote form in the browser, $connectbytessent will return the total number of bytes sent to the browser., e.g. adding a label to the form results in a $ connectbytessent of 2404 bytes, which is the result of the size of the label and the size of the empty form.

* Label object - 207 bytes

Note this is an empty label, so one has to add the number of bytes of text of the label to the above value to get a correct size for the label. The following is a list of the currently available web form objects and the size an empty component requires in a form:

* Empty form - 244 bytes
* Label object - 207 bytes
* Border object - 153 bytes
* Tile object - 133 bytes
* Wash object - 142 bytes
* Calendar object - 378 bytes
* Button object - 302 bytes
* Single line edit object - 316 bytes
* Check box object - 221 bytes
* Radio button object - 3 07 bytes
* List object - 284 bytes
* Droplist object - 278 bytes
* Combo box object - 283 bytes
* Multiline edit field object - 313 bytes
* Headed list object - 356 bytes
* Picture object - 293 bytes
* Button area object - 244 bytes
* Info object - 199 bytes
* JPEG object - 245 bytes
* Movie Player object - 197 bytes
* Formroll object - 273 bytes
* Sidebar object - 323 bytes
* Tabbar object - 295 bytes
* Timer object - 210 bytes
* Webtree object - 329 bytes
* Pagepane object - 355 bytes

With the above information it ought to be relatively simple to determine the number of bytes sent to the browser with $classdata information.

Instance variables

Variables that are calculated in the $construct of the remote form or have been assigned a $initval in the method editor will be sent to the client when requesting a form.

Icon pages

A remote form has a $iconpages property that instructs the remote form to send icons needed in the remote form explicitly to the client. If no icon pages are chosen, objects such as the check box or the radio button will not be displayed correctly. The icon pages are made up of separate portions:
a. the image data
b. the colour map used for the icon page
c. the header information of the icon page
d. the iconid/position values of the icons

An icon page is a memory area which looks as follows:

Header
Colour table of size 2048 bytes
20 icons of size 16x16
20 icons of size 32x32
Unused area
20 icons of size 48x48

The image data is essentially a memory space, similar to a bitmap. An icon page is essentially a 256 colour graphical area which contains all the icon data for all icons in that icon page.

Note that standalone icon pages each have their own colour table, whereas an icon page only has one colour table for all the icons. If one is able to place the icons one needs into one icon page and tries not to use standalone icon pages, one saves sending the 2048 bytes for each standalone icon page.

Font Table #WIWFONTS

If one views the system tables in Studio, one of the tables is the #WIWFONTS table. The $disksize of this class is normally about 520 bytes:

* #WIWFONTS - 520 bytes

Style Table #STYLES

Some web objects support the use of styles, so the #STYLES table has to be passed to the client. This is normally about 470 bytes in size.

* #STYLES - 470 bytes

Background pictures

The web thin client essentially only supports the use of PNGs in the thin client. When one pastes a picture into a form, this is converted to PNG format. The background pictures are not that large due to the conversion to PNG format.

Control Download List

Studio has a datafile called CTRLMGR.df1 which holds the web components for all platforms. When a client accesses a remote form on the server, it uploads the remote form. When creating remote forms, one can add objects to the remote form. These objects have a specific version number which might not be the same as that which is installed on the client. When a remote form is to be displayed in the browser, the thin client compares the version number of the components in the CTRLMGR.df1 to those installed on the client. If the client version of the components is older than those used on the server, the client is prompted to download the newer versions.

Other issues

There are a few other points which have to be mentioned:

* Note: Netscape uses 7 bit encoding whereas the Internet Explorer uses 8 bit encoding.
One is forced to send more data to Netscape than is necessary to send to Internet Explorer.
One can generally say that it is necessary to send 1/3 more data to Netscape than IE.
* It could be an option to use a compression routine when transferring data from the server to the
client and vice versa. This would be especially sensible for the process of initially sending data
from the server to the client. If one takes a normal web form and executes the following code:

Calculate bin as $cclass.$classdata
Calculate #S1 as binlength(bin)
Calculate compbin as compress(bin)
Calculate #S2 as binlength(compbin)

* one will notice that the compressed data is about one sixth the size of the original classdata.
This indicates that it would allow for a dramatic improvement of data transfer from the server
to the client on opening a form if one were to compress the data sent to the client. In an example I
have created in a real application, I have deleted all code in the window and had the following result:

Uncompressed: 44614 bytes
Compressed: 6139 bytes

One has to note that modem users will not notice any speed improvement, as these modems normally automatically perform a compression of the data transferred. With already compressed data this compression is no longer possible. For ISDN or leased line users this compression will, however, be very noticeable.