iShell and iPackager Benchmarks Results.
This is our first article in a series of how you can optimize your iShell title. In the old days of Apple Media Title we did similar technical articles and these articles have been read by thousands of multimedia developers, even today these pages are still visited. <> Even it discuss a different authoring tool, it still has some useful general tips.
Short Description
In this first article we are going to analyze the load performance of iShell: how long it takes to load a .k document and his media and display it. During the development of iPackager we did a lot of speed analyzing on iShell, and the results we give you here are based on these tests. We also compared the speed of iShell with Apple Media Tool, because most of us are familiar with this authoring tool. At the same time we analyzed the influence of the Image Format (PICT, GIF, BMP, JPEG and PNG) on the loading speed.
For those of you who want to do their own speed testing, we added an extra webpage on how we obtained the values of our test case. You have to know that iShell has build in Performance classes. [click here to go to this page]
Optimizing a multimedia title means dealing with some technical issues, in this article I tried to be as "non-technical" as possible, so unexperienced developers could use this article as a starting point in solving speed problems on their own. If some paragraphs are still unclear to you please let me know and I will adapt them.
Introduction
It is important to know that this kind of testing should be your last resort in solving your speed problems. First you should try to reduce the number of elements in your .k document or try to split up your .k document in several .k documents. But we discuss this in depth in future articles. But assume your in the situation that you can't leave anything out and no splitting up is possible, then todays article could help you better understand what you could do to improve the responsiveness of your title. It is very important that your users should have a fast response time when they click on something, this makes your title a lot more fun to explore.
Personally we prefer to build titles where the response time is less then 1 second. On todays low-end PC's (less then Pentium 166mhz and slower then 8x CD) and Macintosh (less then PowerPC 133mhz and slower then 8x CD) the 1 second is sometimes very hard to achieve. Certainly because more and more titles are moving from the standard 640x480 resolution to 800x600. This means a lot more data has to be read from the CD.
Our test case
To measure the performance of iShell we build a small test title.
It has RTF files, QuickTime movies, Sound WAV files and Images. We saved the images in different formats: JPEG (50 % quality), PICT, BMP, PNG, GIF.
The Images are coming from one of the art CD-rom's we collaborated on a few years ago. http://www.magritte.com. These images are all 32-bit, but as you will see, the famous Belgium painter doesn't use much color. Maybe the results would be slightly different if we would have taken outdoor photos but I doubt that the difference will be large. When you start optimizing your title, just take a typical image and compress it in the 5 different formats and see how the sizes are related to our test data.
Our test title has the dimensions of 640x480
Tiny Screen , this screen contains 20 pictures, the images have all a resolution of 104x120. Typical sizes for buttons, thumbnails etc. This is the most occurring element on an iShell screen.
Small Screen this screen contains 20 pictures, the images have all a resolution of about: 212x290. Common used resolutions for flipbook buttons, animations.
Big Screen , this screen contains 12 pictures they all have the resolution 640 x480. These are the typical images for backgrounds or in our case full sized Paintings. Normally you don't have 12 of them on the same screen.
IMPORTANT:
For all images the buffer option was set: When iShell loads such an image, it draws (decompress in case of a JPEG would be a better definition) it immediately in a new offscreen window (hidden window).
Here a small example what happens when iShell loads a screen. Assume we have a screen with just one JPEG file:
Buffer Option case No buffer option
Load .k document Load .k document
Compile/Link .k document Compile/Link .k document
Load JPEG Load JPEG
Create Buffer (dimensions of the JPEG)
Decompress JPEG in new Buffer (and unload JPEG data) Copy JPEG in Screen Buffer Decompress JPEG in Screen Buffer
Copy Screen Buffer to the Monitor Copy Screen Buffer to the Monitor
The results that are shown here below would have been faster, because the buffer options (which is set for all our test images) does two extra operation! In most of the titles the buffer option is set because the second time you have to draw the same image goes very fast!
Buttons and flipbook's are good candidates but also background images because they are also partially redrawn when you update a button image.
Consider the following cases if your hesitating about setting the buffer option:
the offscreen buffer of an image uses also (most of the time) more memory. This is important: in case you want reduce the memory footprint of your title.
you better turn off the Buffer Option for images that draw fast enough (images in PICT format are good candidates).
Today's shipping computers are amazingly fast, so less need for the buffer option! When you know that an image is only going to be drawn once (for example images in a slideshow) you never have to set the buffer option.
But in case you have some sprites flying around the screen, we still strongly recommend the buffer option.
QuickTime Movies , this screen has 10 QuickTime movies, the resolution 156x156. Now that more and more designers are using full animated buttons QuickTime loading is more important.
Sound Files , 20 small wav files on one screen, buffer option was set for all these items.
RTF this screen contains 20 very small RTF files, no antialising set.
We have chosen the file names so that it gives optimal loading results: alphabetical order (physical order on CD) is the order they appear on screen . In real world this is not very often the case, so expect the difference between iShell or iShell + iPackager to be slightly worse.
Test Configuration:
iShell version 1.1.1 was used for these tests.
Macintosh:
PowerPC 7200 90mhz (80 MB Ram)
4xCD-ROM
80MB
System 8.5.1
QuickTime 4.0b21
Monitor 17" inch 1024x768, color depth thousand of colors (16 bit)
Windows 95/NT (service pack 4)
Dual boot system, so Windows 95 and NT were stored on the same machine.
Pentium 200mhz MMX (64 MB RAM)
4xDVD/24 CD
Video Card: Matrox Mystique
Sound Card: yamaha compatible
QuickTime 4.0b21
Monitor 17" inch 1024x768, color depth thousand of colors (16 bit)
In the near future we will add extra tests configurations, for example on a Macintosh G3 and with Windows 98 on PC. We know that these test could be expanded in many different ways, for example compare the different JPEG compressing settings, but this will lead us too far.
Times are in seconds : milliseconds .
Total size is the amount of data that has to be loaded for the complete screen.
Time includes (loading .k document that contains the screen description, compile/link .k document, load for each element his data(draw in their own offscreen windows for bitmap, finally draw everything to the screen)
We only tested the AMT title on MacOS.
AMT 2.1.1
As you can see by these results iShell has become faster in all areas except sound. But we have to remark that AMT 2.1.1 does not load the sound files! It uses an ambient like playback mechanism, that is why the load time were so small. But we have to admit that iShell has slow sound loading, this is caused by the fact it uses the QuickTime API to playback sound. In case it would have used the Sound Manager API, the time would be at least twice as fast. I strongly recommend (if possible) the use of the Ambient Plugin because you would have the same loading results as AMT.
If you take a look at the tiny pictures you will notice that iPackager is also faster then AMT Accelerator. iPackager has a new loading mechanism: while an image is drawn to his offscreen buffer, iPackager keeps on reading data from the disk.
If you look at iShell + iPackager results of Tiny Pictures (01:093) you will see that iShell comes very close to the physical limit: we were testing on 4X CD (maximum data rate 600Kbytes/second) iShell build/draws a screen almost as fast the CD-ROM can read, very impressive results.
<Table>
Conclusions:
OS Comparison.
These results clearly demonstrate that Window NT has a faster read API then Windows 95. I will soon add some results for Windows 98. It is difficult to compare MacOS and Windows, because our windows PC has a very fast CD-ROM drive and also twice as much CPU power.
Which Image format is the right one?
Not an easy decision, because it depends on several factors:
Do you have enough space on your CD?
If no then you better take the smallest size, PNG or GIF or good candidates for small or tiny pictures. But all have their problems PNG changes the colors slightly, GIF supports only 256 different colors in the same image. JPEG is OK but you have to know you loose some quality.
Tiny Pictures case?
PICT, if you have the space because it draws so fast and in case you use the iPackager it is good to know that iPackager has some extra code to accelerate the drawing of images stored in the PICT format.
JPEG in PICT format is slightly slower then JPEG native format, you could also use Cinepak or other codec's...
How much data that has to be read is important. but the Speed of drawing also.
Image quality, let's say you have similar results in difference in sizes you know what kind of results you have. It is good to know that PICT doesn't have any data quality loss, instead JPEG you loose some quality against size of the image.
Faster Machine and JPEG... BIG photos.
iPackager
In all cases iPackager was faster and especially when the images where stored in the PICT format, and iPackager does this on all platforms. With AMT Accelerator there were only a few cases where you could achieve 2 x faster loading times on Windows, but iPackager has much better performance on Windows, thanks to the new loading mechanism: We created an extra loading process that will keep on reading data even if iShell is doing other operations.
Could iShell Go Faster?
iShell results are very impressive, but we noticed that a few things could be faster. Because iShell is based on QuickTime, it is more a problem related to QuickTime then iShell itself.
Thanks to QuickTime 3.0, iShell supports many different Image formats, but the API to read in these different formats isn't the fastest around. We did some test with another JPEG API, and this one was almost 30% faster then QuickTime. (also look at Tidbits here
below)
On MacOS, the same QuickTime Image API (different from QuickTime video API) draws very slow (stops almost) while your are reading data from the CD. That is why on MacOS, PICT files goes much faster in relations with other file formats. On Windows this isn't the case.
Sound could be a lot faster if the Sound Manager API was used. That is why we strongly recommend the use of the Ambient Plugin if possible.
Some small tidbits I discovered:
iShell uses QuickTime API to read in the images in different formats. iShell has some extra cashing code in case you use the same image format directly again. So in case you have 4 JPEG images the first image is loaded a little bit slower, because it needs to load the JPEG Image reader component, the other ones goes faster. iShell cashes only one component, this has the following consequences: The screen with JPEG, GIF, JPEG, GIF will load slower then the order would have been JPEG, JPEG, GIF, GIF.
QuickTime Movies (also QTVR) are loaded before any other media type, no matter their order in the list. For the other media types the order they appear in Element's list is the order they are read from the CD.