cancel
Showing results for 
Search instead for 
Did you mean: 

Problem using cacheReplaceBitmap method.

tarasov.alex.m
Associate III

I tried to use bitmap caching with approach, where I cache all bitmaps except backgrounds during initialization, while background images are cached when changing screens. This method is described here:

https://support.touchgfx.com/docs/development/ui-development/touchgfx-engine-features/caching-bitmaps

This technique assumes that one uses cacheReplaceBitmap method to replace background images in cache. I'm pretty sure that there is an error in this method, and that's why:

While debugging my application, I saw that when I cached background for first screen, it was placed in address X, but the first call of cacheReplaceBitmap copied new image by the address Y, which is not equal to X (actually it is greater than X by the zize of the background). So cacheReplaceBitmap does not replace the bitmap, but rather places new image right after the one I try to swap. I'm assuming, that cacheReplaceBitmap somehow falsely transfers the end address of bitmap to the blockCopy function, when it should be transferring the begining.

Using STM32CubeIDE version 1.3.0 or 1.2.0 (works the same way in either of them) and TouchGFX version 4.13.0

Application is running on STM32F769 DISCOVERY board.

Please confirm this bug, or tell me where I am wrong.

Alex.

8 REPLIES 8
tarasov.alex.m
Associate III

Here's my cache implementation:

FrontendApplication::FrontendApplication(Model& m, FrontendHeap& heap)
    : FrontendApplicationBase(m, heap)
{
    //All except Background
    Bitmap::cache(BITMAP_BLUE_BUTTONS_ROUND_EDGE_SMALL_ID);
    Bitmap::cache(BITMAP_BLUE_BUTTONS_ROUND_EDGE_SMALL_PRESSED_ID);
    Bitmap::cache(BITMAP_DARK_BUTTONS_ROUND_ICON_BUTTON_ID);
    Bitmap::cache(BITMAP_DARK_BUTTONS_ROUND_ICON_BUTTON_PRESSED_ID);
    Bitmap::cache(BITMAP_IMAGEONE_ID);
    Bitmap::cache(BITMAP_IMAGETWO_ID);
    //Background for first screen
    Bitmap::cache(BITMAP_BACKGROUND1_ID);
    backgroundBitmapCached = BITMAP_BACKGROUND1_ID;
}

Each ScreenView.cpp is written this way:

#include <gui/screen2_screen/Screen2View.hpp>
#include "BitmapDatabase.hpp"
extern uint16_t backgroundBitmapCached;
 
Screen2View::Screen2View()
{
 
}
 
void Screen2View::setupScreen()
{
    Bitmap::cacheReplaceBitmap(backgroundBitmapCached, BITMAP_BACKGROUND2_ID);
    backgroundBitmapCached = BITMAP_BACKGROUND2_ID;
    Screen2ViewBase::setupScreen();
}
 
void Screen2View::tearDownScreen()
{
    Screen2ViewBase::tearDownScreen();
}

Martin KJELDSEN
Chief III

Just a note: The images must be the exact same size. But if you're saying you're getting it cached (although not correctly), then they must be.

I'll have to investigate because it doesn't seem like this could happen in our code. The data in the cache is replaced at the spot of the old image id.

/Martin

tarasov.alex.m
Associate III

Hello, Martin,

Indeed, the images are the same size.

I found out, that for my project I will have enough SDRAM memory to store all bitmap data, so I will just use cacheAll(). Nevertheless, I am willing to help to investigate the issue, if you are still interested.

If you have a STM32F769NI DISCOVERY board at your disposal, I can load the project (where I tried caching feature) to the google drive, and leave a link here, so you can test it.

Alex

Martin KJELDSEN
Chief III

That'd be helpful, thanks Alex!

https://drive.google.com/open?id=1ZWktnmqmRJ2C0w8rW5xYaQA6_LOKeLpe

Here is a project, where you can see the mentioned bug.

I've made a new project with small images, so that they fit in internal flash and you won't need any external loader.

By the colour of the button you can see, that GUI changes the screen, but it doesn't change the background.

I've been a bit tied up. Taking a quick look at your running application the background does change for me - I haven't debugged to verify that it's actually getting the data from the cache, but the image is correct given the designer canvas for screen 2.How are you verifying that replace() places the image _after_ your requested location in the cache?

/Martin

alessandro.breuza
Associate III

Hello,

I am facing the same issue on STM32CubeIDE 1.7.0 and TouchGFX 4.17.0.

Any update so far or an hint to solve the problem?

Alessandro

After debugging the cacheReplaceBitmap method, I think the problem may be in the Bitmap::copyBitmapToCache() method: when the BitmapFormat is RGB888, the destination address of the blockCopy is always set to Bitmap::nextFreeData irrespective of the dst passed as argument.