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]

Anybody?

[scottSD]

I found that this also happens when trying to paint a line, circle, or circle progress with an L8_ARGB888 (using PainterARGB8888L8Bitmap).

[scottSD]

I am not getting responses.

I created a simple project with an image formated to default (not L8_ARGB8888). Placing this in a shape in the TouchGFX Designer, it works fine. Then I added a copy of the shape (named differently) and formatted it to L8_ARGB8888.

I manually added this shape and set it's painter to PainterARGB8888L8Bitmap. The code compiles, but I get an assert in the AbstractPainterARGB8888 (which is the base class of PainterARGB8888L8Bitmap).

A little bit more digging and I did find that this painter asserts this when it's not compatible with the framebuffer:

But, according to the L8 article (https://touchgfx.zendesk.com/hc/en-us/articles/360009793299-Using-the-L8-Image-Format)

L8_ARGB8888 should be supported in BOTH Framebuffer formats:

Am I missing something?

[scottSD]

Still no input from anybody. Some help would be appreciated.

I created an image without transparent pixels and added it as the image for a Shape widget. When I set the Image Format to RGB565, the code runs fine.

But if I set the Image Format to L8_RGB565 (no transparent pixels this time), I get the same assert message.

[Martin KJELDSEN]

Hi Scott, i'm going to try to follow up on all L8 questions. Normally i'd be more active, but i'm having a hard time keeping up right now. That'll improve, i promise. I feel guilty leaving you hanging like this 🙂

/Martin

[scottSD]

Thanks for the reply Martin. I figured you were busy.

[Martin KJELDSEN]

Yeah, sorry. I don't think anyone else can answer this. Bare with me - We're working on something awesome =)

[scottSD]

Sounds exciting!

I typically try to figure things out on my own before asking a stupid question. But with this, I was not getting anywhere fast as I wasn't sure if these classes supported L8 or not (no compile time error). I am sure ChromeART supports indexed color images (CLUTs) so I expected these classes to support it as well.

And besides this, I am not sure if it is because of frame buffer configuration or not because when I attempted to change the LTDC in STM32CubeMX, I see that TouchGFX goes to an unconfigured state (in STM32CubeMX > Middleware > Graphics.

Anyway, I am looking forward to that "something awesome". :dizzy_face:

[Martin KJELDSEN]

Briefly, you have to do something additional (in your hal) to make ChromART support CLUT - I will try to do a writeup on L8 hardware support.