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

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

  • May 19, 2020
  • 11 replies
  • 10278 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

    11 replies

    Martin KJELDSEN
    Martin KJELDSEN
    Principal III
    May 20, 2020

    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
    scottSDAuthor
    Senior III
    May 20, 2020

    It appears that it is.....

    0693W000001cbwlQAA.png

    Debug callstack, 0693W000001cbxPQAQ.png

    scottSD
    scottSDAuthor
    Senior III
    May 20, 2020

    @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
    Martin KJELDSEN
    Principal III
    May 20, 2020

    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
    scottSDAuthor
    Senior III
    May 20, 2020

    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
    scottSDAuthor
    Senior III
    May 20, 2020

    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);

    Martin KJELDSEN
    Martin KJELDSEN
    Principal III
    May 26, 2020

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

    /Martin

    scottSD
    scottSDAuthor
    Senior III
    May 27, 2020

    Thanks @Martin KJELDSEN​ , I appreciate it.

    Looking forward to it.

    scottSD
    scottSDAuthor
    Senior III
    June 1, 2020

    @Martin KJELDSEN​ , any updates on this?

    Martin KJELDSEN
    Martin KJELDSEN
    Principal III
    June 2, 2020

    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
    scottSDAuthor
    Senior III
    June 2, 2020

    @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.

    jimmii
    jimmii
    Senior II
    June 4, 2020

    Hi, does this ChromArtDMA also work with L8_RGB565 or only with L8_RGB888?

    Martin KJELDSEN
    Martin KJELDSEN
    Principal III
    June 4, 2020

    Should work for both :) Side note: One of my teams tasks next sprint is to add support for L8 through TouchGFX Generator.

    jimmii
    jimmii
    Senior II
    June 8, 2020

    Hi @Martin KJELDSEN​ 

    I gave it a try: When working with 16bit RGB565 and ARGB8888 (non opaque) the chromartdma is working fine.

    But when using it with L8_RGB565 and L8_ARGB8888 something is going wrong. (See attached pictures)

    Any ideas, hints?

    0693W000001qFJfQAM.jpg

    This is what it should look like0693W000001qFJGQA2.jpg

    Thanks, /jimmii

    scottSD
    scottSDAuthor
    Senior III
    June 9, 2020

    @Roman Schläpfer​ 

    Just a thought, have you experimented with the different "Dithering" settings?

    jimmii
    jimmii
    Senior II
    June 10, 2020

    Thanks @scottSD​ 

    I did, but the only thing it changed was the look of the artifacts.

    nico's cat
    nico's cat
    Associate III
    June 16, 2020

    I have the same problem.

    I did a finger drag image experiment.

    When the picture is in L8 format , the setupDataCopy() will be never called . So is it completely done by the CPU?@Martin KJELDSEN

    This is my interface:

    0693W000001qlU6QAI.png

    1: L8_RGB888

    2: L8_RGB565

    3: ARGB8888

    When I drag image1 or image2 by finger , the setupDataCopy() will not be called.

    When I drag image3 the setupDataCopy() will be called.

    Martin KJELDSEN
    Martin KJELDSENBest answer
    Principal III
    June 16, 2020

    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

    nico's cat
    nico's cat
    Associate III
    June 16, 2020

    Where can I get it ?:smiling_face_with_smiling_eyes:

    Show more replies
    Terms & ConditionsAccessibility statement