On Mon Jun 3 13:07:01 2024 +0000, Rémi Bernon wrote:
The macOS driver always use `biCompression = BI_RGB`, which means that the `bmiColors` field isn't used. When `biCompression = BI_BITFIELD`, the first three `bmiColors` elements provide bit masks for the R/G/B colors in the bitmap (so you can re-order them for instance). Another semantic difference, and that's what `wineandroid` is doing, is that `biBitCount = 32` + `biCompression = BI_RGB` implies that the alpha channel is valid in the most significant bits. Otoh `biBitCount = 32` + `biCompression = BI_BITFIELDS` implies that the alpha channel should be ignored (or that there is none, for instance with a `R11B10G11` format which could be described through the `bmiColors` field, though that's only theoretical). For the purpose of window surfaces, having an alpha channel or not has some implications on whether the surface can be used for layered windows or not. Ultimately I think we could perhaps use 32-bit surfaces with alpha channel all the time, but right now each drivers manages that a bit differently.
Thank you for the extensive information.
Consistently using 32bit surfaces with alpha makes sense, although it's best to have those done incrementally ... IIRC we had some perf regressions in Mesa/i965 with similar a change.
HTH o/