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.
>
An application should query if the xserver has render support and if
not take appropriate decisions. No? E.g., in FVWM we have a function
which simulate XRenderComposite and a font spec can have two fonts one
for Xft and an other one for core text rendering.
> 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
>
In some case it is not the number of colors which counts but how the
apps share the colours. XFree-4.2 run in mode #6 (TrueColor) and you
will have no problems with GTK and QT apps, Xemacs, FVWM and probably
others apps (do not test Mozilla neither OpenOffice) as a lot of apps
use a 6x6x6 cc (by default or because the app detects such allocated
cube). So even with XFree-4.2, in some environement, you have 12 free
colors until you start an "old" application. As with XFree CVS if you
start one KDE apps you have no more free colours. Moreover, if you use
standard dithering methods, dithering is really really better in mode
#5 and #6 than in the default mode. So I think that
-render-colors lotof - mode #5
-render-colors full - mode #6
can be usefull. Mode #5 is intersting, a lot of apps can use a 5x5x5
cc and the standard ordered dithering gives good result (it is the
minimal "default" cc used by GTK) and in the other hand you have a
reasonable number of free colours.
Yes, using StaticColor is more or less equivalent than mode #6 (but
with a bit different colours proportion (3/3/2) by default). I think a
"full" mode does not hurt and assure backward compatibility. But, I do
not care. I am more interested by mode #5.
An other subject. Do you think that it is better to always use
pow(2,k) grey colours (e.g., use 16 grey for the default in the place
of the 21 grey) so that the grey are aligned with the 32x32x32 colour
cube which is used to "approximate" the render colors?
I make some tests and this seems ok.
Regards, Olivier
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
