Update of bug #20632 (project gnustep): Item Group: None => Bug
_______________________________________________________ Follow-up Comment #1: It looks like the byte swapping for the colour mask produced a nonsensical result in your case. I really don't know, when and why this byte swapping is needed, but in some cases it results in the wrong mask. Looking at the Xlib documentation (Vol 1, pages 178+179) I see that there are a lot more bit and byte order combination than the code in art supports. The current byte swapping approach sure only works for some 24 and 32 bit formats. For your 16 bit format it is bound to fail. One thing that you could simply try is to switch off the byte swapping by uncommenting this block in ARTContext initWithContextInfo: { int us = byte_order(); /* True iff we're big-endian. */ int them = ImageByteOrder(d); /* True iff the server is big-endian. */ if (us != them) { visual->red_mask = flip_bytes(visual->red_mask); visual->green_mask = flip_bytes(visual->green_mask); visual->blue_mask = flip_bytes(visual->blue_mask); } } But I don't expect that to work correctly, at least you would end up with supported colour masks. Just a few days ago Andreas Höschler reported a similar problem to the discussion mailing list "Weird color problem with GNUstep/Etoile". In his case the ARTContext seems to get initialised six times, which looks totally wrong to me. _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?20632> _______________________________________________ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ _______________________________________________ Bug-gnustep mailing list Bug-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnustep