Around 22 o'clock on Oct 22, David Dawes wrote:
> > -no-render-extension / NoRenderExtension
> > -render-extension (for cancelling a NoRenderExtension option in
> > XF86Config)
Might shorten these to '-norender' and '-render'. However, I'd argue that
Render should be considered a "core" extension and not be made optional at
all. Applications like OpenOffice and Mozilla will not function
reasonably without it, and (see below), it's impact can be mitigated or
even eliminated, although some apps will probably produce "unexpected"
results without any render colors in the default colormap aside from black
and white.
I note that we don't have a '-noshape' option available.
> >cl GreyScale PseudoColor
> >--------------------------------------------
> >0 : default default
> >1 : 8 grey 8 grey
> >2 : 16 grey 2x2x2 cc + 4 grey (or 8?)
> >3 : 32 grey 3x3x3 cc + 8 grey (or 16?)
> >4 : 64 grey 4x4x4 cc + 16 grey (or 23?)
> >5 : 128 grey 5x5x5 cc + 16 grey (or 32?)
> >6 : 256 grey 6x6x6 cc + 32 grey (or 30)
> >
> > -render-color-limit (int)cl / RenderColorLimit (int)cl
This seems more like a mode to me, and it seems like fewer choices would be
better. Certainly mode #6 is not useful as it's identical to a static
colormap, except that the server won't do any nearest color matching. I
suggest three models would be sufficient:
-render-colors none - render uses only BlackPixel and WhitePixel
-render-colors few - render gets 16(?) levels of gray
-render-colors default - render gets a modest number as in current CVS
'few' mode will still be very useful in displaying AA text while consuming
only a small part of the colormap, while 'none' eliminates any impact on
the colormap while still permitting applications to accelerate non-AA
client-side text.
Keith Packard XFree86 Core Team HP Cambridge Research Lab
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
