EVALUATION
According to xdpyinfo user has 24 bits per RGB pixel.
Unfortunately the ThreeByteRgb loops are not yet implemented.
###@###.### 2001-10-22
There are some video boards like the submitter's Matrox Millenium II and the
ATI Radeon 9700 that report having 24 bits per pixel, with a 3 byte pixel
stride, with the ordering R, G, B. It turns out that we check the component
masks returned by X11 for the visual and if the red mask is 0xff0000, we mark
the surface as ThreeByteRgb. However, as far as our software loops are
concerned (and X11 as well), these surfaces are better described as
ThreeByteBgr. We already have ThreeByteBgr loops in place, so the fix here is
fairly simple: just mark these surfaces as ThreeByteBgrX11 rather than
ThreeByteRgbX11.
Most everything works after making this change, except for
the case when remote displaying from solaris-sparc to linux-i586. Because the
endianness of the systems are different, we attempt to swap the bytes when
using XGetImage() and XPutImage(). However, for some reason, this swap is
unnecessary in this configuration, so the fix here is to avoid the swap if
the configuration is 24 bpp, 3 byte pixel stride, and the red mask is 0xff0000.
###@###.### 2002-11-01
|
Java