Optimize Non-Executable Files (Compact 2013)
3/26/2014
In addition to placing non-executable files in the FILES section of the .bib configuration file, you can take the following steps to optimize how the system loads and uses these files:
- Use appropriate image-file resolution. Including an image file that is of higher quality than your device display can waste ROM space, so you should use image files that match the resolutions and color depths of your system display screen. Doing so eliminates lag time for the system to resize or otherwise adjust image files for display on the device screen.
If you use multiple display configurations, consider specifying the file to use for each display by using multiple image files with IF/ENDIF statements in the configuration file. However, note that including multiple copies of the image file increases overall OS image size. - Use appropriate image file format. Experiment with different image formats to identify which one displays with the best quality and fastest load time. For example, try using a compressed format such as .jpg or .gif instead of .bmp.
- Generate simple images programmatically. For example, instead of rendering an image file, consider generating a solid background color or other simple image to eliminate the memory consumption required by images files.
- Choose the appropriate bit rate for audio files. Audio bit rate affects the amount of data the system buffers for playback. For example, the Buffering Stream Filter in DirectShow uses a 1 MB buffer by default. This size allows the buffer to store 64 seconds of data at 128 kbps, but only 25 seconds of data at 320 kbps.
- Reuse multimedia files. Consider reusing image and audio files that are already in ROM to minimize system latency when the system must access the file repeatedly.
- Package your data properly. Use multiple execute-in-place (XIP) regions to package your data in terms of locale, resolution, and other variable properties. This enables the OS to run code directly from ROM rather than loading it into RAM. By using multiple XIP regions instead of a single region, you can divide the ROM image into discrete parts. For example, if your project supports different resolutions and color depths, put your resolution-related modules into separate binary image (.bin) files instead of putting them all in the same .bin file. That way, you can pick the .bin that is most appropriate for the project. For information about how to specify multiple XIP regions, see Romimage Tool (romimage.exe).