Hello @Dadigno ,
Using latest TouchGFX, STM32CubeIDE and STM32CubeMX.
I have created a TouchGFX project using a STM32U5G9J DK2 (16 bits image color depth and 800*480 screen resolution).
I have created an image with transparency using Gimp.
I have added that image to my TouchGFX project.
I have also added a button to go to screen 2 (empty screen) and a button on screen 2 to go back to screen 1 to try to trigger the blockcopy function when going back to screen 1 (with transparency image).
I have also added a moving box to see hardfault in case it happens.
Case 1 : When the image is in RGB565 (section and extra section in internal) it works fine but the transparent pixels are turned black, there is an extra section.
Case 2 : When the image is in ARGB8888 (section and extra section in internal) it works fine but the transparent pixels are turned black, I can see the image being 4*800*480bytes=1.46Mb in the internal flash region, no extra section.
Case 3 : When the image is in ARGB8888 (section and extra section in external) it works fine, I can see the image being 1.46Mb in the external flash region, no extra section.
Cases X : Tried the same things with your image (bg_2.png) and got the same results.
In either case I cannot reach breakpoint on blockcopy, seems like blockcopy is never called.
I repeated the tests using colored images with and without transparency, and the results are always the same. It doesn't matter if the image is colored.
Yes, It was mostly to verify the behavior visually.
If you use an image with transparencies with the designer and set the type to RGB565, all the bytes corresponding to the transparencies are collected in the extra section. Is this expected behavior and is it then handled by the core in the rendering phase even when using external memory? Can you try it yourself?
I had the same behavior. But the behavior of RGB565 is only there for debugging in our case, we only care about ARGB.
ARGB worked fine for me.
I cannot debug the blockcopy because, in the case of images with transparencies saved in external memory, it is not called!
Since it works for regular image and because we have not found anything related to the blokccopy function, we can assume here that it works fines and look for something else.
I've done some tests and it seems it doesn't work this way either: using the ARGB8888 type with a non-transparent image saved in the external memory generates a hardfault in the blitCopyARGB8888Solid function without the blockcopy function being called. Can you check too?
Here is the definition of the blitCopy function:
/**
* Blits a 2D source-array to the framebuffer performing alpha-blending per pixel as
* specified. If ARGB8888 is not supported by the DMA a software blend is performed.
*
* @param sourceData The source-array pointer (points to the beginning of the data). The
* sourceData must be stored as 32 bits ARGB8888 values.
* @param source The location and dimensions of the source.
* @param blitRect A rectangle describing what region is to be drawn.
* @param alpha The alpha value to use for blending applied to the whole image (255 =
* solid, no blending)
*/
static void blitCopyARGB8888(const uint32_t* sourceData, const Rect& source, const Rect& blitRect, uint8_t alpha);
/**
* Blits a 2D source-array to the framebuffer never performing alpha-blending per pixel as
* because it is assumed that all pixels in the bitmap are solid (i.e. alpha for each pixel is
* 255).
*
* @param sourceData The source-array pointer (points to the beginning of the data). The
* sourceData must be stored as 32 bits ARGB8888 values.
* @param source The location and dimensions of the source.
* @param blitRect A rectangle describing what region is to be drawn.
*/
void blitCopyARGB8888Solid(const uint32_t* sourceData, const Rect& source, const Rect& blitRect) const;
Using the verb blit which means "The term "blit" is short for "block image transfer" and is a computer graphics operation in which a block of pixels is copied or moved from one area in memory to another."
So it is similar to block copy but for transparency images.
I get an hardfault at the blitCopyARGB8888 function if the top-left image starts with at least one transparent pixel, while I get an hardfault at the blitCopyARGB8888Solid function if the image starts with colored pixels (transparency in the middle). I suppose these functions are called for a portion of the image at a time and based on whether or not they contain transparent pixels.
In the description of the function they say "a 2d array" but they do not mention if it is just part of the image or the full image. Either way, at some point, it will find a pixel that has transparency completely different than the previous ones.
However, they mention 32 bits.
Can you check your linker script and make sure that your external memory is aligned for 4 bytes like so (this is the linker script of our TBS for the STM32U5G9J DK2):
ExtFlashSection :
{
*(ExtFlashSection ExtFlashSection.*)
*(.gnu.linkonce.r.*)
. = ALIGN(0x4);
} >EXT_FLASH
}
If that doesn't solve your problem.
Can you please tell me which version of tools you use.
Also, what MCU are you using?
Regards,
Gaetan Godart
Software engineer at ST (TouchGFX)
