Hello,
in fact Embedded Wizard implements many measures to avoid that images occupy RAM unnecessarily. Which measures are existing in your system will depend on the version you are using. The section Surface Cache and Bitmap Resource Treatment describes the available configuration switches.
The above mentioned optimization measures controls when images are loaded and whether they are retained in so-called 'surface cache'. It controls thus the behavior when an image is already accessed (in use). Images which are not in use are never loaded.
In your case (and depending on your Embedded Wizard version) you will need to do following:
Step 1: The image has to be accessed (used) in advance before the screen is presented. To achieve that, add a new variable to your Application component. Configure the type of the variable to be Resources::Bitmap. Configure the Generator attribute of the variable to be true in order to avoid elimination of that variable since it is not used elsewhere in the project. Then assign your bitmap resource to this variable. Following screenshot demonstrates such variable:
Step 2: Test the modification in Step 1.
With Step 1, the bitmap is accessed in advance AND it will remain referenced during the whole runtime of the application. This may eventually be sufficient for your application - depending on the version of your Embedded Wizard system.
Step 3: If it was not sufficient (you still observe a delay when entering the screen), you are working with a version configured to 'lazy load' bitmaps. See the documentation referenced at the beginning of my answer. In such case ensure EW_LAZY_LOAD_BITMAPS_IF_ANIMATED_ONLY is configured with 1 and EW_DISCARD_BITMAPS_IF_ANIMATED_ONLY is configured with 1.
Please note, the modification in Step 3 will affect the loading and caching of all bitmaps in your application. Possibly, the bitmaps will occupy more RAM.
ALTERNATIVE APPROACH: If you have enough ROM and your platform does supports the mode 'DirectAccess', you can configure the bitmap with Mode DirectAccess. Then there is no decompression of bitmap contents at runtime provoking the delays. The bitmap is drawn directly from the ROM. Following would be the configuration of a bitmap:
An additional advantage of this approach could be that handling other resources remain unchanged.
A disadvantage can slower screen update when drawing a bitmap stored in DirectAccess mode. This depends however on your target system and requires tests.
I hope it helps you further.
Best regards
Paul Banach
