Why does animating an L8 image take significantly longer than a standard image?

[scottSD]

I have been experimenting with animating an image onto the screen. Because I want to reduce the amount of FLASH space required, I would like to use an L8 image (I do appreciate adding this format to the TouchGFX framework, by the way).

I am placing the image in a container and I have selected the MoveAnimator Mixin for that container.

However, I notice that the amount of time it takes to animate this container from off the screen to on the screen takes significantly longer when the image is formatted as an L8 (either L8_RGB565 or L8_ARGB888). When I say significant, I am saying it takes up to 50mS as compared to 12mS.

Am I doing something wrong? Is it possible that the DMA2D (ChromART) not working correctly for L8's?

I am using TouchGFX 4.13.0 and my processor is an Stm32H743.

[Martin KJELDSEN]

My guess is that your ChromART/DMA2D class doesn't support L8. Break inside setupDataCopy() to figure out if it's getting called for the image being moved.

[scottSD]

It appears that it is.....

Debug callstack,

[scottSD]

@Martin KJELDSEN​  in previous versions of the Stm32CubeIDE (1.1.0), there used to be ChromArtDMA (cpp and hpp) files in the TouchGFX/target directory. I see that those are no longer in that directory when using the new CubeIDE version (1.3.0). I assume this is because the new Application Templates no longer use these drivers?

[Martin KJELDSEN]

It's actually CubeMX (through TouchGFX Generator) that does the code generation, and since CubeIDE embeds CubeMX, etc.. complex! The files would be named after the MCU family you're using, e.g. STM32H7DMA.cpp. ChromArtDMA.cpp/hpp are files i shared some time ago - Maybe they were copied manually by you? They're not a part of the code generation scheme for TouchGFX Generator.

/Martin

[scottSD]

Below are some code snippets to show you that I am formatting the image as an L8:

Screen1ViewBase.hpp:

touchgfx::MoveAnimator< touchgfx::Image > imagePopIn;

Screen1ViewBase.cpp:

imagePopIn.setXY(0, 0);
    imagePopIn.setBitmap(touchgfx::Bitmap(BITMAP_B5_MENUPOPIN_260X260_ID));

Source code of that bitmap (to show it is an L8):

// 4.13.0 dither_algorithm=2 alpha_dither=yes layout_rotation=0 opaque_image_format=RGB565 non_opaque_image_format=L8_ARGB8888 section=ExtFlashSection extra_section=ExtFlashSection generate_png=no 0x9e0d7fea
// Generated by imageconverter. Please, do not edit!
 
#include <touchgfx/hal/Config.hpp>
 
LOCATION_PRAGMA("ExtFlashSection")
KEEP extern const unsigned char _b5_menupopin_260x260[] LOCATION_ATTRIBUTE("ExtFlashSection") = // 260x260 L8 indexes.

Screen1View.cpp (Initially off the screen):

    imagePopIn.setPosition(270, 480, 260, 260);

Screen1View.cpp (Code I am calling to animate the image onto the screen):

imagePopIn.startMoveAnimation(270, 229, 20, EasingEquations::linearEaseNone, EasingEquations::linearEaseNone);

[scottSD]

That is correct, I do remember now. They were files I did get from you and then copied manually because at that time, DMA2D was actually not supported without those files.

Here is the thread you provided those for me:

https://community.st.com/s/question/0D50X0000BdgJZkSQM/is-the-l8argb8888-image-format-supported-for-shapes-widget-if-not-will-it-be-in-the-future

[scottSD]

As I stated in the post description. When the image is formatted as an L8, the animation onto the screen is very choppy.

I don't see where the CLUT is even referenced in STM32H7DMA, so i am wondering if it does support L8.

Is there anyway you can test this out yourself?

[scottSD]

I am using my own custom board. I don't have an STM32H743I-Eval, but I just created a project based on that Template and compared the stm32h7xx_hal_dma2d.c between my project and the one created by the Application Template and they are identical.

As I stated, I do not have an STM32H743I-Eval, so I cannot test it's performance.

[scottSD]

@Martin KJELDSEN​  any thoughts on this? Do you still think its possible the ChromART/DMA2D class doesn't support L8?