[bug #20632] unrecognized color mask in art

[Fred Kiefer]

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/