Re: GNUstep and 256 colors.

[Marko Riedel]

Hello there,

there was a discussion about this on September 23 of this year (subject
screen grab recipe).

The problem lies with the implementation of the draw mechanism
XGDM_PORTABLE (files XGServer.m and XGBitmap.m). It does not use a color
cache on pseudocolor visuals, but rather queries the color for every pixel
when it composites bitmaps. This could be fixed with a cache. Here's what
I wrote at the time:


2. As the writers of XGServer well know, XQueryColor can be very
   slow. In fact the current implementation is not usable at all on
   PseudoColor displays. Maybe we should use a cache here, the way I
   did in the recipe. Imagine your basic XEmacs window, say 400x400,
   which is mostly grey, black and white, with a couple more greys
   thrown in. This kind of pixmap would require maybe ten or fifteen
   calls to XQueryColor if a cache were used, as opposed to 160000
   calls with no cache, if I understand correctly.

Here is an excerpt from XGBitmap.m:

      /*
       * This block of code should be totally portable as it uses the
       * 'official' X mechanism for converting from pixel values to
       * RGB color values - on the downside, it's very slow.
       */


You might have to make a case that there still are enough pseudocolor
visuals out there to make fixing this worthwhile.

I'm not sure I explained this very clearly as it's been two months --
maybe  someone else will clarify this further.

Best regards,


=====
+-------------------------------------------------------------+
| Marko Riedel, EDV Neue Arbeit gGmbH, markoriedelde@yahoo.de |
| http://www.geocities.com/markoriedelde/index.html           |
+-------------------------------------------------------------+

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de