loadResource Out Of Memory Error Details: Failed invoking <symbol>

Hi, I was loading drawables with the code below.
var bgBitmap = Ui.loadResource(Rez.Drawbles.bg);
The peak mem used is 43kB but in which case I got an OOM error. Curious about why?
Device: fr245(m) (CIQ 3.3.1)
SDK: 6.3.0
  • Incredible! The size becomes 60kB after being loaded!

    That sounds plausible if the image is 240 x 240 resolution (same as the fr245 screen resolution) with 8 bits of color.

    240 x 240 x 1 byte = 57600 bytes

    It sounds like you could save memory by disabling transparency and using a palette:

    https://developer.garmin.com/connect-iq/connect-iq-faq/how-do-i-optimize-bitmaps/

    RGB222

    Some devices have 64 available colors. These colors are chosen using 2 bits for red, 2 bits for green, and 2 bits for blue. The graphics system will internally represent bitmaps as 8 bits per pixel.

    ...

    If you have a low color image, reducing the bit depth can save precious runtime memory. By setting the import palette, you can communicate the total number of colors the image should use.

    ...

    On 16 color and RGB222 devices the resource compiler automatically uses an extra color - the transparent color - to represent transparent areas. Disabling transparency tells the resource compiler that the image doesn’t have any transparent areas, saving one color in the converted image and potentially reducing bit depth. With the four colors set and transparency resource compiler creates a 4 bit image; with no transparency it will create a 2 bit image for a 50% memory savings.

    In general, use low bit depth images to save memory when possible. If you have a logo that can be represented with a small number of colors, use the palette and disable dithering to make a sharper image with a lower bit depth. Remember: great looking 16 color images will work across all wearables. 64 color images add some shading options, but you’ll need to weigh the balance of image quality and memory savings. Edge bike computers have better color representation, but using high bit depth images can quickly eat your runtime memory as well.

  • Thanks Sir. I will try.