On Tue, Oct 22, 2002 at 08:08:24PM -0700, Keith Packard wrote: >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.
If it can be run in a mode where no colours other than black or white are allocated, then that'd be OK. It needs to be possible to have a configuration where legacy pseudocolor-only clients can run without interference. I can't think of too many reasons why people would choose to run in 8-bit mode other than to be able to run such clients. >I note that we don't have a '-noshape' option available. That's because people don't complain about shape affecting the operation of legacy clients :-). >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. That sounds reasonable to me. It also simplifies the implementation (unless we want to be able to set these options per-screen from the config file). David _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
