Michel D�nzer wrote:
On Fre, 2003-02-07 at 21:36, Alexandr Andreev wrote:
Bool
XAACheckStippleReducibility(PixmapPtr pPixmap)
{
...
pPriv->pattern0 = bits[0] | SHIFT_L(bits[1],8) | SHIFT_L(bits[2],16) | SHIFT_L(bits[3],24);
pPriv->pattern1 = bits[4] | SHIFT_L(bits[5],8) | SHIFT_L(bits[6],16) | SHIFT_L(bits[7],24);
...
}
where SHIFT_L(value, shift) is defined as ((value) >> (shift)) for Big Endian.
SHIFT_L really means shift right for big endian machines!
Bool XAACheckTileReducibility(PixmapPtr pPixmap, Bool checkMono) { ... pPriv->pattern0 = bits[0] | (bits[1]<<8) | (bits[2]<<16) | (bits[3]<<24); pPriv->pattern1 = bits[4] | (bits[5]<<8) | (bits[6]<<16) | (bits[7]<<24); ... }
Here is the true shift left.
Yes of course, but In the first case the __most__ significant byte of the bits[0]In both cases the unsigned int bits[] array contains bytes!No, in XAACheckStippleReducibility() it's declared as CARD32.
contains data and in the second case the __last__ significant byte of the
bits[0] contains data. So, you obtain swapped pattern0 and pattern1 in the "tile"
case.
I don't see any obvious problems with this code, and it's been working perfectly on several big endian machines I've used. Maybe you need to set some more XAA flags and/or swap bytes in the driver? Look at the radeon, r128 and glint drivers for examples.
There is only one flag in XAA which can have an influence on ordering in 8x8 Pattern Fills - BIT_ORDER_IN_BYTE_LSBFIRST / _MSBFIRST, but it specifies bit ordering not byte. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
