Hi Jim, > Perhaps the difference is that Dmitri is running on a display with Xbgr > which has to decompose the argb value and recompose it into a BGR value > - in the process it only moves the r, g, and b bits around. > > Clemens is running on an Xrgb screen and so the pixelconverter just > passes on the argb value as the pixel - alpha bits and all - as he > discovered. Thanks for the detailed analysis.
> That's safe for most purposes since the alpha value should > be ignored, but causes a problem with this "+1" hack. I think we ran > into a case internally where the extra bits of the pixel value did cause > a problem with some of the Solaris X11 drivers, but we proposed that it > was a violation of X protocol and the driver was fixed. > > The simplest fix would probably be to just mask off the alpha in > rgbToPixel and stop "playing with fire" by leaving the alpha bits set. > This could also be done more specifically in the BlitBg support code > (mask the pixel and +1 to see if it is set yet or not). The most robust > fix is to add a boolean as originally proposed... I also thought about howto explain that I think the +1-hack is no good idea because such code is hard to read and could be broken unintentionally ... however on the other side it maybe uses more memory (haven't looked at the struct) so its a space/readability tradeof. Well but most time people prefer their code over others so I thought I am not in a good position to discuss this ;) What do you think about using the boolean approach and masking the pixel-value in rgbToPixel()? Could it break things or limit functionaliy? Thanks for looking into this, lg Clemens
