The difference between FrameDelay and Timer Slot

Question

Hi EW team,

I'm using a multi-frame bitmap(32000*320) to do animation (screen size is 640*320). If I set the "FrameDelay" of the bitmap to 40, and set the "Animated" of a Image to true, the animation will be played normally by 25fps.

But if I set the "FrameDelay" of the bitmap to 0, and use a timer(Period is 40) slot to change the FrameNumber of the image, like this:

slot onTimer
{
  if(this.Image.FrameNumber >= 49)
  {
    this.Image.FrameNumber = 0;
  }
  else
  {
    this.Image.FrameNumber = this.Image.FrameNumber + 1;
  }
}

The animation will be played for several frames, and disappear because of out of memory.

Can you please tell me the difference of these two methods? Why using "FrameDelay" can cost less memory than timer slot?

Thank you !

Answer 1

Hello,

in fact the both methods are similar. The difference is that if a Bitmap Resources is configured as animated (its attribute FrameDelay > 0), the memory usage of the bitmap may differ at the runtime. For example, the loading of bitmap frames may be delayed and unused frames may be discarded early. If the bitmap is not considered as animated, the frames may be retained in bitmap cache or even all frames may be loaded in advance. The exact behaviour is configurable via macros found in the ewconfig.h file belonging to the Build Environment. For example, the macro EW_LAZY_LOAD_BITMAPS_IF_ANIMATED_ONLY configures whether delayed loading of bitmap frames should apply to animated bitmaps only.

You could try following configuration. It imposes all bitmaps (animated or not) to be lazy loaded and discarded quickly:

#define EW_LAZY_LOAD_BITMAPS                              1
#define EW_LAZY_LOAD_BITMAPS_IF_ANIMATED_ONLY             0
#define EW_DISCARD_BITMAPS                                1
#define EW_DISCARD_BITMAPS_IF_ANIMATED_ONLY               0
#define EW_DISCARD_BITMAPS_IF_NOT_USED_IN_CURRENT_UPDATE  0
#define EW_DISCARD_BITMAPS_IF_NOT_USED_IN_RECENT_UPDATES  0
#define EW_CACHE_OFFSCREEN_SURFACES                       0

So far the technical background. Anyway, you should consider that a 32000x320 pixel large bitmap will possibly occupy a lot of ROM (code memory) unless the bitmap contains large similar looking areas, so they can be compressed well. You could try to configure the bitmap as stored in Index8 format. Such bitmaps occupy less memory. On the other hand they are more CPU intensive when displaying them.

I hope it helps you further.

Best regards

Paul Banach