STM32L4R9-DISCO DSI example - sample image not actually RGB

[JSome.2]

I recently purchased an L4R9 Discovery board with an MB1314 round LCD.

Under STM32Cube_FW_I.4_V1.17.2 / Projects / 32L4R9Discovery / Examples / DSI / DSI_CmdMode_SingleBuffer, there is a reference to a 24bpp frame buffer. The comment cryptically states:

/* Physical frame buffer for background and foreground layers */
/* 390*390 pixels with 24bpp - 20% (with GFXMMU) */

20% is not explained. Furthermore, the sample code goes on to draw a bitmap from a header file into the buffer:

/*Draw image in GFXMMU (Chome-GRC) Virtual buffer*/
CopyInVirtualBuffer((uint32_t *)image_390x390_rgb888, (uint32_t *)LAYER_ADDRESS, 0, 0, 390, 390);

But the data in "image_390x390_rgb888" isn't actually just RGB data. If you look at the header file containing the data, it's formatted into blocks (horizontal lines?) and each line cryptically begins with an undocumented byte - at a glance, it appears to be always 0 or 1.

So my questions are:
1. What is 20% referring to?
2. What is the extra byte in the RGB data of the header file?

[KDJEM.1 · Accepted solution]

Hello @JSome.2 ,

GFXMMU enables to store only the visible parts of the non-rectangular displays and in the case of round displays, this peripheral reduces by 20% the memory requirements to store the graphic framebuffer.

So, GFXMMU allows an economy of about 20% of the framebuffer memory footprint, despite the overhead of the pixels that are mapped but not visible on the display. For more explanation, I advise you to refer to AN5051
Application note "Graphic memory optimization with STM32 Chrom-GRC™".

I hope this answer your request!

Thank you for your contribution in STCommunity :).

Kaouthar