bugGNUstep - Bugs: bug #20632, unrecognized color mask in art

Group
 
 

bug #20632: unrecognized color mask in art

Submitter:  Riccardo Mottola <rmottola>
Submitted:  Mon 30 Jul 2007 07:24:05 PM UTC
   
 
Category:  Backend Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 21 Jun 2010 08:58:55 PM UTC, comment #3: 

It seems to work now, although I don't remember exactly how I generated it, I opened some apps on a 16bit display (exactly the  NetBSD one used originally).

Riccardo Mottola <rmottola>
Group Member
Wed 20 Aug 2008 07:18:31 AM UTC, comment #2: 

I tried to improve the byte swapping for the 16 bit case. Could you please retest with recent art backend from the SVN repository.

Fred Kiefer <FredKiefer>
Group Member
Tue 07 Aug 2007 10:07:13 AM UTC, 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.


Fred Kiefer <FredKiefer>
Group Member
Mon 30 Jul 2007 07:24:05 PM UTC, original submission:  

2007-07-30 21:09:33.794 FTP[1018] gnustep-back(art): Unrecognized color masks: 00f80000:e0070000:1f000000 16
2007-07-30 21:09:33.803 FTP[1018] Please report this along with details on your
pixel format (ie. the four numbers above) to bug-gnustep@gnu.org.Better: implement it and send a patch.)


on NetBSD 3.1 X11

Riccardo Mottola <rmottola>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by rmottola (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-06-21 rmottola StatusReady For Test Fixed
        Open/ClosedIn Test Closed
    2008-08-20 FredKiefer StatusNone Ready For Test
        Open/ClosedOpen In Test
    2007-08-07 FredKiefer Item GroupNone Bug

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code