Color handling bug in STemWin library?

Louie88 · ‎2021-07-09

Because nobody answers my questions I begun to investigate myself and found a very interesting thing. The STemWin manual suggest if I want to use the ARGB colors (instead of ABGR) then I have to add a definition into the GUIConf.h file:

#define GUI_USE_ARGB                  (1)

But this definition already exists, except its value = 0 not 1

#define GUI_USE_ARGB                  (0)    /* The color format to use is ARGB */

In the comment ST says the ARGB format is selected with GUI_USE_ARGD = 0! . So, finally which color format is selected?

The GUI_USE_ARGB is used in many files, like in GUI.h, LCD.h, GUIConfDefaults.h and GUIConf.h. In GUI.H, but it is very funny:

#if (GUI_USE_ARGB)
  #define GUI_BLUE          0xFF0000FF
  ...
#else
  #define GUI_BLUE          0x00FF0000
  ...
#endif

Should not it be like this?

#if (GUI_USE_ARGB == 1)
  #define GUI_BLUE          0xFF0000FF
  ...
#else
  #define GUI_BLUE          0x00FF0000
  ...
#endif

Then look at the blue color definition above. The 0xFF0000FF is the ARGB8888 format, but this definition is excluded from the file and 0x00FF0000 is used, which is the ABGR8888 format. Now the LCD screen in the STM32H7I-DISCO board supports ARGB format, but if you set the background color to GUI_BLUE then it will be transparent red, because the GUI_BLUE = 0x00FF0000, where ALPHA = 0x00 (transparent), RED = 0xFF, GREEN = BLUE = 0x00.

Even all the colors compiled into the code begins with 0x00, which is a non-visible color.

Regardless of this, the following code causes RED background on the LCD:

GUI_SetBkColor(GUI_BLUE);
GUI_Clear();

I think not only the GUI_USE_ARGB is used faulty but there is something wrong with the ALPHA channel handling. Why? Because in the above code I set GUI_BLUE which is equal to transparent red but the background of the LCD is not transparent (black?) but something like red. I tested the opposite to prove myself that I am right:

GUI_SetBkColor(GUI_RED);
GUI_Clear();

The RED background color occurs BLUE background. But it should be transparent because the ALPHA channel = 0x00.

Using GUI_TRANSPARENT (0xFF000000) color occurs BLACK background:

GUI_SetFont(&GUI_Font8x16);
	GUI_SetBkColor(GUI_TRANSPARENT);

Note: I exactly know that in ABGR8888 color format the A (ALPHA) channel is reversed (0x00 is the opaque and 0xFF is the transparent color)

Finally: Because all the colors compiled into the STemWin based app begin with 0x00 all the printed text, graphics should be invisible because ALPHA = 0x00 is transparent color in ARGB8888 mode. This might answer my other topic Why does not the LCD update in STM32H747I-DISCO board? The text is on the LCD just it uses invisible color?

Thanks,

Louis

Louie88 · ‎2021-07-12

I imported stm32_lcd.c file from the official BSP example. I resolved a lot of include files, finally I could run the example, which simply worked. I have 4 LEDs on the LCD screen and touch X/Y position display in the bottom line. If I touch any LED it changes its state on the screen (turns it ON if it was turned OFF and reverse) and in addition it also turns ON/OFF the hardware LED on the DISCO board in synchrony with the LCD LEDS. On the attached photo the orange and the blue LEDS are turned on while the green and red LEDS are turned off.

Of course, this app does not use STemWin library. Instead of the STemWin library it uses the functions implemented in stm32_lcd.c file, like UTIL_LCD_DisplayStringAt(), UTIL_LCD_DrawEllipse(), UTIL_LCD_FillEllipse() and many other functions.

Of course the STemWin library a very complex library with window handling and with other nice functions, but the stm_lcd.c “library�? is good enough to demonstrate how the display, buttons, interrupts work in STM32H747I-DISCO board.

If somebody has the same problem what I have then I suggest to use the stm_lcd.c file. Open/Import the STMicroelectronics “BSP�? project. Find the “Utilities/stm_lcd.c�? file and import it into your project. Resolving the include files is a nightmare, but it is not mission impossible.

This test proved that the board is good, the LCD refresh error is not hardware error. The bug is somewhere in the STemWin library. Most like in the ARGB8888 color handling.

Best regards,

Louis