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]

It does. I don't think you have the right Chromart class. It's a bank holiday here, just doing a presentation and then i'm off again, and tomorrow as well, so i'll have to get back to you monday.

[scottSD]

OK, thanks for replying. I would really appreciate it if you could look at it.

Enjoy the time off!

[Martin KJELDSEN]

Back from bank - holiday - I'll try to get around to updating you on this.

/Martin

[scottSD]

Thanks @Martin KJELDSEN​ , I appreciate it.

Looking forward to it.

[scottSD]

@Martin KJELDSEN​ , any updates on this?

[Martin KJELDSEN]

Hi @scottSD​ - Sorry for the slowness. On top of a bunch of bank holidays we're also moving to a new office.

Just to summarize, my initial thought was that your chromart/DMA2D class does not support L8 - It's not something we generate, at least. There's an ongoing task now for us to implement it inside the TouchGFX Generator, and until then i released a small sample project that had an L8 updated chromart class.

It seemed like your setupDataCopy() gets called, but it's not taking proper care of L8, so does it actually look correct for you on display? Are you sure this call to setupDataCopy() was for a chunk of an L8 image?

Thoughts?

/Martin

[scottSD]

@Martin KJELDSEN​  I appreciate the reply.

Actually, the L8 looks fine on the display.

It is more of an issue of how long it takes to animate to the display when using startMoveAnimation(). It is quite a bit slower and takes several frames (50mS as compared to 12mS when the image is not formatted as an L8).

As I stated above, I am using my own custom board and I don't have an STM32H743I-Eval to test, but I 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.

It is a rather simple experiment to try and I was wondering if you could see if you are seeing the same symptom on a STM32H743I-Eval.

[Martin KJELDSEN]

Okay, so it looks fine, but setupDataCopy() gets called - this must be for a different part of an image. Can you verify? This is my theory, anyway. You don't have the chromart class with L8 support, it looks like. The H743I-Eval AT definitely does not have it - But i posted it somewhere here on the forum.

[scottSD]

Thanks @Martin KJELDSEN​ , I will do some more research. It definitely looks like this is the case.

As far as where you "posted it somewhere here on the forum", I assume you're talking about the following post where you provided me with L8ChromARTDMA (about half way into the thread)?

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

I had thought that the latest Application Templates were supporting L8's in ChromART, but apparently that's not the case.

[Martin KJELDSEN]

And you'd be right to think so. But it's been on hold while we got the Generator up to speed on L8. And you're right, that's the thread.