Decompressing certain rotated ARGB8888 bitmaps hangs
Hello
I’m using TouchGFX 4.26.0 on a STM32H747 and want to use RGB compression of the bitmaps to get the size of the firmware image smaller. To prevent performance loss, all bitmaps are loaded into the cache at startup. I have enough free SDRAM for the cache, so this is the easiest method and doesn’t require manual maintenance when adding / removing bitmaps to the project.
Because the displays native orientation differs from the application orientation, image rotation is set to 90° by default.
The code to load the bitmaps is shown below. This function is called at the end of TouchGFXHAL::initialize()
void loadAllBitmapsIntoCache()
{
const uint16_t totalBitmaps = BitmapDatabase::getInstanceSize();
for (uint16_t id = 0; id < totalBitmaps; ++id) {
touchgfx::Bitmap bmp { id };
auto format = bmp.getFormat();
bool ok;
if (format == touchgfx::Bitmap::BitmapFormat::COMPRESSED_RGB565
|| format == touchgfx::Bitmap::BitmapFormat::COMPRESSED_ARGB8888
) {
ok = touchgfx::Bitmap::decompressRGB(id); // <- Hangs here for certain rotated bitmaps, probably depending on their size, e.g. 264 x 42 or 110x105
}
else {
ok = touchgfx::Bitmap::cache(id);
}
assert(ok);
}
}
Observations
- As noted in the code comment, Bitmap::decompressRGB() hangs endless for certain ARGB8888 images, probably depending on their pixel dimensions.
- The problem disappears, when I turn off rotation and everthing runs fine except that the images look garbled of course.
- The program also runs fine with rotation and no compression, or when loadAllBitmapsIntoCache() isn’t called at all.
For completeness, here’s the call stack when execution is stopped:
touchgfx::Bitmap::decompressARGB8888(unsigned char*, unsigned short)@0x0807950c
touchgfx::Bitmap::decompressRGB(unsigned short)@0x08079b86
(anonymous namespace)::loadAllBitmapsIntoCache@0x0805ca82
(anonymous namespace)::initializeBitmapCache@0x0805cab6
TouchGFXHAL::initialize@0x0805cbfa
touchgfx_init@0x0805d920
Mmi_Init@0x0805c5ba
RunInitTask@0x0803c9de
There’s probably a bug in Bitmap::decompressRGB() which doesn’t take image rotation into account.
Did anybody notice this too?
Peter
