Display buffer color formats in TouchGFX

[bear2023R]

I’ve already asked and didn’t get any answer to the following question: how did it happen that TouchGFX, being ST product, does not support the very basic HW feature of each and every LTDC interface in STM32 controllers, namely – L8 (8bpp) format with hardware palette (look-up table) and the second layer with blending?
Do similar limitations apply to other HW features as well or it is just L8 was that unlucky after so many years of TouchGFX development? Last CubeMX version with StemWin and dual layer with 8bpp support was 6.4.1, already coexisting with TouchGFX for few years. Now is CubeMX 6.9.2, TouchGFX 4.22.1 – and still very basic yet very important feature is missing, forcing to double memory requirements for GUI application where more than 256 colours are not necessary. GuiX provides that feature but also didn’t get any official ST support despite clear move towards ThreadX.

We are a big ST customer for years, and are in the process of selecting GUI library at the moment. The lack of 8bpp support by TouchGFX, dropped full-featured StemWin, and exclusion of full-featured GuiX from otherwise fully supported ThreadX, brings some questions on what is the TouchGFX future and where is it going if it didn’t receive a full support even for basic HW native STM32 features until now?

What level of GUI applications TouchGFX is targeting without using external RAM? Dual display buffer even at 480x272 resolution and with 2-byte per pixel, like in TouchGFX, consumes 512K of RAM. How many STM32 variants provide that much, still leaving some space for other tasks?

Are there any plans to add one-byte-per pixel support to this library in any near future?

The ST answer will be greatly appreciated.

Thanks

[MM..1]

Where you read this fame ? L8 normaly work. And dual layer too but manualy managed. One example inner frame is L8 TGFX layer over layer ...

[bear2023R]

I read this fame here (looks like official documentation to me):

https://support.touchgfx.com/docs/basic-concepts/color-formats#framebuffer-formats

Framebuffer formats​

Not all image formats are available as framebuffer formats. The L8 formats cannot be used as framebuffer formats in TouchGFX. This is because it is not practical blend to two images in the framebuffer.

....

Framebuffer format Order Description

ARGB8888	BGRA	32 bits, 8 bits per component
XRGB8888	BGRX	32 bits, 8 bits per component, alpha byte ignored
RGB888	BGR	24 bits, 8 bits per component.
RGB565		16 bits, 5 bits red, 6 bits green, 5 bits blue
ARGB2222		8 bits, 2 bits per component
ABGR2222		8 bits, 2 bits per component
RGBA2222		8 bits, 2 bits per component
BGRA2222		8 bits, 2 bits per component
GRAY4	LSB	4 bits grayscale
GRAY2	LSB	2 bits grayscale
BW	MSB	1 bit grayscale

 

L8 is not listed above. The documention is incorrect?

[MM..1]

No and yes , all 2222 is L8

[bear2023R]

So, the documentation is misleading, at least, that's what you are trying to say?

IN the very same document:

https://support.touchgfx.com/docs/basic-concepts/color-formats#rgbx2222-xrgb2222-bgrx2222-xbgr2222

uint8_t brightYellowRGBx2222 = 3 << 6 | 3 << 4 | 0 << 2;

That's what is in TouchGFX and that's what is going to be displayed
uint32_t ABGR_to_display = ((abgr2222 << 6) | (abgr2222 << 14) | (abgr2222 << 22) | (abgr2222 << 30)) & 0xCCCC;
While brightYellowRGB for L8 supposed to be:
uint32_t ABGR_to_dispaly= LUT[brightYellowRGB_L8];
where LUT is look-up table

This is very different, I guess, both in treatment and possible colors it may present.
Surely, manually all x2222s can be made treated as L8 by employing LUTs, but I wouldn't call it by any means "native support by TouchGFX for L8 format" - as manfully you can do a lot, even write a whole new library from scratch. What's the point in one you have though, then?. And that's why documentation didn't claim it either. 

I'm glad though that it is not a "fame" anymore but rather "yes and no" now.)) Although, seems like that is rather "no".
So the question remains the same: is there any plan to make support for L8 in TouchGFX?

[MM..1]

---

@bear2023R wrote:

The documention is incorrect?

---

When your "no" negate your question, then = documentation is correct. 

L8 CLUT is generated in TouchGFX target code and used for convert images and gui. Your code examples is irelevant LTDC CLUT is hw based and TouchGFX must place to framebuffer memory right 8bit. HW use table to show. Maybe you try stop teory and use L8 .

[bear2023R]

---

@MM..1 wrote:

... Maybe you try stop teory and use L8 .

 

---

Basically, it transforms in to "may be you stop reading documentation", and try using something that documentation says the library doesn't support. I understand, thanks. Documentation is  fame, anyway.))

Support for L8 is not just about a pure display. For instance, finding a matching or closest color is very different for A2222 and L8. Blending, keyed transparency etc. Yes, I know, everybody can do it manually.)

Well, thanks for your explanation on how to use/extend TouchGFX anyway.