Oh man, why must graphics be so frustrating sometimes...
It is the purpose of the RawImage.Description.Init_XXXX procedure to define the order of the red, green, blue, and alpha channel bytes in the pixels. In my code, using an array of TColor, I am putting values into the data array which have red in the least-signficant byte 0, green in byte 1, blue in byte 2, and the alpha (transparency) channel in the most-significant byte 3 - because we're working with 32-bit colors. This is important information for the bitmap drawing procedure to extract the color channels of each pixel from these array values in the order needed.
Why is the Linux output empty? I think, this is because of the alpha channel. In TColor the alpha byte of "normal" (= non-system) colors is zero.Windows did not use alpha for a long time and thus is ignoring it in its default GDI drawing methods (used by the LCL TBitmap). In Linux, however, the alpha channel always has been there and is being used for painting. And Alpha = 0 means: fully transparent!
How to fix it? I tested paweld's idea: it does display something in the paintbox now, but the colors are changed. No, I think the lsb-to-msb order of RGBA is correct, but we only must provide a correct (=opaque) alpha channel. This can be done by an extended RGBToColor function which explicitely sets all bits in the alpha channel ($FF):
function OpaqueColor(r, g, b: Byte): DWord;
begin
Result := r + g shl 8 + b shl 16 + $FF shl 24;
end;
Of course, this is no real "TColor" any more, it works only in conjunction with pf32bit bitmaps where the RawImage.Description provides the information where the color channels can be found. Assigning it to a Brush.Color or Pen.Color will result in some different color because the LCL interprets the lsb as indicator of system colors. Therefore it is better to store some "neutral" type in the data array, such as a DWord.
See attached modified project which works in Win, Linux gtk2/gtk3/t5/qt6, cocoa.