[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #20632] unrecognized color mask in art

From: Fred Kiefer
Subject: [bug #20632] unrecognized color mask in art
Date: Tue, 07 Aug 2007 10:07:13 +0000
User-agent: Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.5 (like Gecko)

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 

      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:


  Nachricht geschickt von/durch Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]