Around 9 o'clock on Oct 23, Olivier Chapuis wrote: > 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.
Client-side text is a powerful mechanism which is not easily replaced with core fonts. Xft uses the core protocol GetImage/PutImage when Render is not available, but performance suffers greatly. Applications like OpenOffice (and FrameMaker) are unable to provide reasonable text output with the core font primitives. Client-side text is useful independently from anti-aliasing. > In some case it is not the number of colors which counts but how the > apps share the colours. Our working assumption is that 8-bit PseudoColor displays are useful only for legacy applications; those don't generally share well with others as they need custom or writable color values. Any significant number of preallocated color cells generally cause these applications to fail. > 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 doesn't (currently) support dithering, and dithering to a random set of colors is rather expensive. I like having both a color cube and a gray ramp as I believe that provides more accurate anti-aliased text, I'm not sure how dithering fits into this model. > Yes, using StaticColor is more or less equivalent than mode #6 (but > with a bit different colours proportion (3/3/2) by default). The new fb frame buffer code fits the largest color cube and fills the remaining entries with a gray ramp, precisely as you've described for mode #6. PseudoColor with a completely allocated colormap is a poor substitute -- with StaticColor, the server will automatically fit new color requests into the existing color entries, while PseudoColor will fail the allocation request. > I think a "full" mode does not hurt and assure backward compatibility. > But, I do not care. I am more interested by mode #5. Any PseudoColor mode which doesn't permit the bulk of legacy applications to run without problems isn't interesting in this context; it may be that the 'default' mode can allocate a few more colors than it does in current CVS, but I don't think it should use a 5x5x5 cube > 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? That's a good idea; we could actually eliminate the entries in the gray ramp duplicated within the color cube. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
