Is the L8_ARGB8888 image format supported for Shapes widget? If not, will it be in the future?

[scottSD]

Let me preface this question by saying I appreciate the new L8 (indexed) color support for many of the widgets. This includes the support for L8s in dynamic bitmaps.

I attempted to use an image formatted to L8_ARGB8888 in a shape widget. The code compiled, but when running on the simulator I received the following assert:

The painter for the shape is not instantiated as an L8_ARGB8888, but a PainterRGB8888Bitmap as seen in the gui_generated Screen1ViewBase.hpp file:

Does the shape widget support the PainterARGB8888L8Bitmap? If not will it support it in the future?

[scottSD]

The gui_generated Screen1ViewBase constructor calls shape1Painter.setBitmap(), passing it the Bitmap I added in the Designer:

shape1Painter.setBitmap(touchgfx::Bitmap(BITMAP_BOX_R_BLACKNOALPHA100X100_ID));

This bitmap has a valid bitmap ID.

However, when I run on the STM32CubeIDE 1.1.0 debugger and place a breakpoint on the assert in the following code:

void PainterRGB565Bitmap::setBitmap(const Bitmap& bmp)
{
    bitmap = bmp;
    assert((bitmap.getId() == BITMAP_INVALID || bitmap.getFormat() == Bitmap::RGB565 || bitmap.getFormat() == Bitmap::ARGB8888) && "The chosen painter only works with RGB565 and ARGB8888 bitmaps");
    bitmapRectToFrameBuffer = bitmap.getRect();
    DisplayTransformation::transformDisplayToFrameBuffer(bitmapRectToFrameBuffer);
}

The value of bmp's ID is 0xffff (BITMAP_INVALID). Is this a bug?

[Martin KJELDSEN]

And if you check the source code for BITMAP_BOX_R_BLACKNOALPHA100X100_ID (generated/images/src/box_blacknoalpha100x100.cpp) What does the image format comment tell you? It's not the right format for an RGB565Painter

e.g.

LOCATION_PRAGMA("ExtFlashSection")
KEEP extern const unsigned char _blue_buttons_round_edge_small[] LOCATION_ATTRIBUTE("ExtFlashSection") =   // 170x60 ARGB8888 pixels.
{
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
...

 Wasn't your intention to use the L8 Painter? (In this case for RGB565).

void PainterRGB565L8Bitmap::setBitmap(const Bitmap& bmp)
{
    ....
    assert((bitmap.getId() == BITMAP_INVALID || bitmap.getFormat() == Bitmap::L8) && "The chosen painter only works with appropriate L8 bitmaps");
    ....
}

/Martin

[scottSD]

Martin,

I really do appreciate the reply. I believe there is a bug in the TouchGFX Designer. Its something you should really look into.

Yes, the source code for my bitmap says it is an L8.

KEEP extern const unsigned char _box_r_blacknoalpha100x100[] LOCATION_ATTRIBUTE("ExtFlashSection") =   // 100x100 L8 indexes.

And yes, my intention IS to use the PainterRGB565L8Bitmap. However, as I showed in my previous post, Screen1ViewBase.hpp is creating a PainterRGB565Bitmap object. Not an L8 one:

touchgfx::Shape<4> shape1;
touchgfx::PainterRGB565Bitmap shape1Painter;

I believe there is a bug in the TouchGFX Designer code generator (or whatever you call it) which creates the gui_generated code.

I altered the Screen1ViewBase.hpp code to create an PainterRGB565L8Bitmap object instead (and over wrote the read-only file) and when running on the target, it functioned correctly. Of course I can't test it on the Simulator because that regenerates the gui_generated files.

[Martin KJELDSEN]

I just tried it and you are absolutely right. Somehow we've forgotten to consider the image format of the image being used for the "Image Painter", so its still only based on the general bit depth of the application.

You've found a bug =) Thanks!

/Martin

[scottSD]

Martin,

Thanks for taking the time to verify this.

The thing I am still a bit confused about is how the system handles L8 images with alpha. When I format the image as an L8_ARGB8888 and then manually edit the gui_generated Screen1ViewBase.hpp so that it uses a PainterRGB565L8Bitmap painter:

    //touchgfx::PainterRGB565Bitmap shape1Painter;
    touchgfx::PainterRGB565L8Bitmap shape1Painter;

The code compiles and executes on the target correctly even though the image is formatted with alpha and I am not using a painter with alpha.

Because of the format of the image, I tried PainterARGB8888L8Bitmap so that it matches the format of the image. It compiles but does not execute correctly on the target.

Maybe I'm not understanding the painters correctly, but shouldn't this work in the system?

[Martin KJELDSEN]

Actually, the name PainterARGB8888L8Bitmap means ARGB8888 is the target framebuffer pixel format (32-bit). While RGB565 L8 is targeting a 16-bit framebuffer.

[scottSD]

Martin,

Thanks! That clarifies it for me. It took me a while to understand, but I see now that since I am using the STM32F746G-Discovery kit (which is using LCD16bpp) I need to use PainterRGB565L8Bitmap.

[Martin KJELDSEN]

Exactly right. I don't blame you for not understanding it, haha. It was difficult coming up with a class name that had both the framebuffer pixel format and source image format 🙂

/Martin

[scottSD]

Martin,

This has nothing to do with the L8 topic of this thread, but more to do with the ChromArtDMA files you posted here.

I was researching the STM32F7DMA::setupDataCopy() function some more because I was wondering about a performance issue and whether or not the ChromArt is being used.

You said in this thread (above) that "it shouldn't" get to that function in the original code (STM32F7DMA). But when I debug, it does get to this function.

I noticed that the variable disableChromArt is set to false in STM32F7DMA.cpp

volatile bool disableChromArt = false;
 
BlitOperations STM32F7DMA::getBlitCaps()
{
    if (disableChromArt)
    {
        return static_cast<BlitOperations>(0);
    }
    else
    {
        return static_cast<BlitOperations>(BLIT_OP_FILL
                                           | BLIT_OP_FILL_WITH_ALPHA
                                           | BLIT_OP_COPY
                                           | BLIT_OP_COPY_WITH_ALPHA
                                           | BLIT_OP_COPY_ARGB8888
                                           | BLIT_OP_COPY_ARGB8888_WITH_ALPHA
                                           | BLIT_OP_COPY_A4
                                           | BLIT_OP_COPY_A8);
    }
}

If I set that variable to true and debug, it does not get the STM32F7DMA::setupDataCopy() function.

Should it be set to true in STM32F7DMA.cpp?

[scottSD]

Martin,

I checked the release notes for TouchGFX 4.13.0 and I could be wrong, but I didn't see this listed in the many fixed bugs.

Do you know if this issue is fixed in 4.13.0?