Comment Re:One problem. (Score 3, Informative) 163
The original X graphics infrastructure was pretty badly broken, worse in some ways than the Windows API. X doesn't provide any color information about pixels, so it's actually not possible to know what colors different pixel values mean in different contexts. The only place you can be sure is when drawing to windows, and you can only generate intermediate color values for TrueColor windows.
The Windows API provides color information everywhere instead of pixel information; applications select the color for text, not the pixel values. Each pixmap contains information about what colors are represented by pixel values. This makes anti-aliasing quite possible and ensures that drawing in different contexts will generate consistent results.
If you're interested in bit-level pixel manipulation and complete control over the hardware colormap, then the core X rendering system is just the ticket. All of the limitations we're running into now were caused by compromises necessary to support commercially important applications in the era X was developed; now that hardware is 1000 times faster, we can emulate those tricks and still provide new capabilities.
However, it's even more important to realize that anti-aliased text is only a side-effect of the real benefits that Fontconfig and Xft bring to X. The core protocol font handling has never been sufficient to support sophisticated text display. Every sufficiently powerful text rendering engine based on X has had to give up on the core fonts and implement text entirely in software. From TeX previewers to commercial publication systems, none of them gain any benefit from the hardware acceleration and network bandwidth optimizations of the core text primitives.
Furthermore, the core protocol font support cannot handle Unicode encoded fonts -- character codes are limited to 16 bits and Unicode requires 24. Even if you limit applications to the Unicode basic multilingual plane, the metrics information cannot be compressed as it is delivered over the wire or stored in Xlib making applications consume huge amounts of memory storing arrays full of zeros.
It is possible to kludge in AA text support for applications using the core protocol, but the results would be inconsistent on the screen and such support would not do anything to fix the worst limitations of core fonts.
As Xft2 now supports legacy X servers (without Render support), it is now reasonable to consider jettisoning any support for the core protocol fonts and switch to only supporting client-side fonts. Servers with Render will get good performance while servers not yet fixed will still work reasonably well.
The last step to take is to make all of the core bitmap fonts available as Unicode bitmap fonts through Fontconfig. The original plan was to make FreeType able to read the existing compressed bitmap font file formats that XFree86 uses. Those formats still suffer from the encoding assumptions that drove the massive space consumption in the core protocol metrics data, plus such fonts are consistently encoded in Unicode.
The new plan is to reencode the existing core fonts as TrueType fonts with only bitmaps for each glyph. The TrueType spec has explicit support for such fonts. Reencoding the fonts will significantly reduce the amount of disk space consumed by the fonts, eliminate all of the existing bitmap readers from the X server (and font server) and simultaneously make the fonts available to fontconfig/xft2-based applications.
