32 bit display and bitmaps

[maxerist]

The code with 24 bit/32 bits bitmaps worked flawlessly either in VMs or from RDP. But the Windows RDP client can be forced to use arbitrary bit depth for color, 24 or 32 bit (in the login window before the connection). And in this case, for 32 bit I started seeing different unexpected effects when drawing bitmaps. From semi-transparent effects to out of sync columns drawing.

Although there's no way to see the depth in the Gnome' gui window, I can detect the bit depth with xwininfo command. When the issue is visible the command xwininfo -root | grep "Depth" shows "32". When everything is ok it's 24.

I suspect that it has something to do with xrdp implementation so I wanted to check this in the VM, but to my surprise there's no reliable way to change the depth to 32 bit in linuxes. All those hints involve manual creating and editing xorg.conf file and warns that there are risks. 

Did someone meet such issues before? Should I just see this as a xrdp issue and be sure that lazarus/gtk2 does everything right?

Thanks

[maxerist]

Additional information

I could not force a Virtual Box guest linux to use 32 bit color depth no matter what. So the following is done with Rdp connected to xrdp server. So, the good case is when I choose 24 bit for Screen before connecting to a linux machine, the bad one - when I choose 32 bit

The following screenshot were made with the sample program
\examples\canvas_test\canvastest.lpi
by clicking "Draw Dialog". As you can see, the bad one just draws nothing.

Some guesses that might leas to understanding what's going on

• My tests with different RGB numbers makes me think that for some reason B channel is used both as transparency and the blue one. At least I managed to reproduce the wrong drawing of yellow (with 128 blue) bitmap over a blue form when applied 50% transparency in a graphic editor.
• The code that implements bitmap drawing for gtk2 looks very solid and I saw no real difference depending on the current color depth. For example, gdk_pixbuf_new_from_data always uses alpha channel and in case the 4th byte has some unexpected values, this should be visible in both modes.
• As for xrdp to blame the jury is still out there. gnome-screenshot makes the same file as the current screen so I thought this is a pro for xrdp to being correct. Also googling ["xrdp" "32 bit" "24 bit"] shows some reports when a user complained about programs (not all) being unexpectedly transparent. But given that Windows Rdp client might suggest 32 bit color depth very often by default, for xrdp to do something wrong the reports should appear more often.