Why is framebuffer RGB565 using RGBA8888 and not RGB565A8

Question

Hello,

Why looking at Assets.c for code generated for an image with a iMX_RT_BBK profile, for the NXP.iMX_RT.RGB565 platform (Embedded wizzard 9.0).

The doc (even for 9.10) https://doc.embedded-wizard.de/platform-package?v=9.10 cleary states that framebuffer RGB565 uses the RGBA8888.

I do not understand why RGB565A8 is not used, it would save 8 bit per pixel (and proably save compuations since 8bit→5bit or 8bit→6bit should be done on runtime rather than at compile time).

Thanks,

Marc.

Answer 1

Hello Marc,

the RGB565A8 color format means that a bitmap consists of one memory area containing the 16bit per pixel RGB565 values and another memory areay containing the 8 bit per pixel Alpha values.

This format was introduced many many years ago for one hardware that was only able to operate with two different memory areas.

In principle, your proposal to use RGB565A8 instead of RGBA8888 for bitmap resources is a good idea to reduce the footprint. Unfortunately, this format is not advantegous for software drawing routines and it is not supported by most hardware graphics accelerators.

You already found parts of version 9.10 documentation online - this version will be released next week. With version 9.10 the Platform Package and Build Environments for NXP i.MX RT1050 and RT1060 will use the pixel pipeline hardware (PXP) in order to accelerate fill / copy / blend operations. This would be not possible with RGB565A8 resources.

Btw: We are just discussing to treat RGB565A8 and RGB555A8 as deprecated.

Best regards,

Manfred.

Comments

Thanks for quick answer Manfred,

 

Unfortunately, this format is not advantegous for software drawing routines 

I still do not understand why, since the framebuffer only understands RGB565 and this format (RGB565A8) holds:

- a bthe framebuffer with RGB565

- the Alpha values for all the pixels in a separate memory area

The drawing routines "only" have to manipulate 565 formats (that could be compiled) rather than working in 888-space and converting it at runtime to 565-space. Or is is the manual alpha computation (565 → 565 by a 8-bit value) that is "complicated" ?

Thanks,

Marc

---

It is not a question of 'complicated', it is more a question of performance. In case that the bitmap resources (which means the source in a copy or blend operation) are stored in RGB565A8 format, the software blending takes more CPU cycles for every pixel compared to RGBA8888. For blending operations every pixel is separated into the R, G, B components in order to make the blending.

For the framebuffer (which is only a destination in all drawing operations) there is no need to have a separate alpha information.

But anyhow - the goal of every Embedded Wizard Platform Package is to get the best performance by using hardware acceleration. In case of RGB565A8 there is no hardware support in almost all MCU/MPUs.

In order to reduce the memory footprint within the FLASH it might be helpful to use the option Compressed for bitmap resources.

Best regards,

Manfred.