Skip to main content
scottSD
Senior III
May 19, 2020
Solved

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

  • May 19, 2020
  • 67 replies
  • 10529 views

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.

This topic has been closed for replies.
Best answer by Martin KJELDSEN

If you don't have the ChromartDMA class i shared in this community, then yes it's drawn by CPU. Working on adding support to the Generator so that it can generate L8 support for all MCUs in the TouchGFX DMA class.

/Martin

67 replies

SMour.1
Associate III
June 4, 2021

@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