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]

@scottSD​ @Roman Schläpfer​ 

Actually, L8_RGB565 is not supposed to work - ChromART cannot handle that format. But it should not crash, it should use the software fallback. So that's the actual issue.

/Martin

[Martin KJELDSEN]

​Would you mind attaching the chromart L8 class here? Just so i know which version i'm looking at - I'll check it for potential issues. Hope it's fixable in this "public" patch and not something that requires a new library (LCD Classes divert tasks to either software or specific ChromART implementations)

/Martin

[scottSD]

@Martin KJELDSEN​ 

OK, that makes sense. I have just decided to not use L8_RGB565 which doesn't effect me that much because most of the images I will use will include alpha anyway.

As far as attaching the chromart L8 class, I just want to make sure I attach the correct thing you are asking for..... Are you referring to the files you gave me a while back (ChromArtDMA.cpp and ChromArtDMA.hpp) ?

If not, which files are you referring to?

[Martin KJELDSEN]

Yes, those files. Thanks

[scottSD]

@Martin KJELDSEN​ 

Attached.

[scottSD]

I guess it won't let me attach two files, so here's the cpp.

[Martin KJELDSEN]

Thanks!

[SMour.1]

@Martin KJELDSEN​ 

Hi there and thanks for the amazing job.

I am currently using 4.16.1 and I would like a catch up to know if there is an official solution/patch to the problem above. As you mentioned it should have been up on 4.15.*

Furthermore just to be sure I would like some insight for the usefulness of each feature on my usecase. I have an stm32h743vit custom board, an external flash of 16Mb with quad spi and an spi screen 320*240 rgb565 .As expected I would like to add as many images as I can to the flash and I would like to do most of the computations on the chrom-Art dma2d instead of the cpu (the second part is more important).

The question is quite simple.

1. Should I use L8_RGB565 when possible for minimum flash consumption or it will unavoidably clutter my cpu?
2. If choice one is inapplicable should I use L8_RGB888 instead and expect chrome-art to assist my cpu better even though it will have to modify the images to RGB565 after the conversion from L8 to non L8 ?I am aware that L8_RGB565 and L8_RGB888 have insignificant data size differences.
3. If choice two is inapplicable should I use normal rgb565?

I should be able to answer this question alone but my current input is a bit contradicting as the reference manual of stm32h7 at page 721 https://www.st.com/resource/en/reference_manual/dm00314099-stm32h742-stm32h743-753-and-stm32h750-value-line-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf states that chrom-art can use only l8_rgb888 (so choice number two) but the current thread suggests that for an stm32h7 not to use l8 at all or use the cpu with l8_rgb565