Around 22 o'clock on Nov 6, Olivier Chapuis wrote:
> Maybe ok for some text (but you risk black on black and white one white).
> But take the new cursors, the result is catastrophic.
Some applications may not work optimally on PseudoColor hardware when the
user selects mono mode; it should be no different from running on
monochrome displays. Given that Xft can be configured not to use the
Render extension, it seems like we're providing extra flexibility here by
providing a limited Render extension. I hope few environments require the
'mono' mode.
> I will send a patch soon.
I'm busy hacking your previous patch in; I'm nearly done. It's uncovered
several less than optimal parts of the existing design, so it's not quite
as straightforward as I would have liked.
> But FindBest{Color,Gray} assume that the allocated colors by
> miBuildRenderColormap are consecutive (which is the case in practice).
I don't think so; they work on StaticColor/StaticGray visuals as well for
which no colors are preallocated.
> BTW, it seems strange to have only 13 grey for GrayScale visual
> with 256 cmap entries.
Yeah, caught that today. The color allocation policy now only affects how
colors are allocated out of the default colormap. For visuals other than
the default visual, the whole colormap is used. For pseudo color,
we get a 6x6x6 cube and 46 gray levels. For testing, I added an 'all'
mode and discovered to my delight that Gtk+ and Mozilla were both quite
happy to run with no free colormap cells -- somehow they discovered the
6x6x6 cube and used it. Spooky.
Keith Packard XFree86 Core Team HP Cambridge Research Lab
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
