Time for X12? [LWN.net]

Time for X12?

Posted Apr 3, 2003 9:50 UTC (Thu) by MathFox (guest, #6104)
Parent article: A discussion with Keith Packard

First I'ld like to say that, despite its age, X is a great piece of software engineering. As Keith notices, it shows its age: the extensions to the X11 protocol have grown in importance over the X11 core protocol. If we would have the chance of redesigning the X11 protocol, without having to worry about backwards compatability, what new features would we include and which obsolete features would we drop.

The first things to include would be vector (OpenGL-style?) graphics and scalable, anti-aliassed fonts. I see this as a step towards a resolution-independent graphical protocol. A shift to a global RGBα color model would be logical looking at font anti-aliassing.

If you provide anti-aliassed fonts, it makes sense to drop the current font mechanism. I think the pixel-oriented operations should remain in X12, to allow for emulation of the X11 interface; make them depricated so that we could drop them in X13.

Overall my proposals would favour the TrueColor over the PseudoColor (paletted) displays. It's a price I don't mind to pay considering the advance in graphics hardware over the last decade.

Peter Roozemaal

(Log in to post comments)

Time for X12?

Posted Apr 3, 2003 14:47 UTC (Thu) by jamesh (subscriber, #1159) [Link]

Why on earth would you need to break compatibility with all existing X applications to implement any of those features?

We already have antialiased fonts (through Xft2), and will be getting a good 2D vector API soon (the Xr/Xc client libraries that use the RENDER extension). Further more, the RENDER extension allows you to composite images in RGBA space. All this is possible without breaking every existing X application.

As fontconfig and Xft become more popular, the legacy core X font system will fall into disuse (currently there is only one or two applications on my desktop using core fonts). At that point core fonts may even get switched over to use fontconfig to find fonts, in which case you wouldn't even need to bother configuring the legacy font support.

Time for X12?

Posted Apr 3, 2003 21:47 UTC (Thu) by spitzak (guest, #4593) [Link]

You don't have to "break compatability". What is needed (and is missing
from X right now) is a clear decision that the new interface is the
STANDARD, not an "extension", and THE OLD INTERFACE SHOULD BE EMULATED
ATOP IT.

For instance, multiple visuals and pseudo color are easily emulated
without breaking any applications. Any applications that expect a
"visual" must list the available ones, and they will be told there is
only one (a 32-bit rgba truecolor visual). And a vast chunk of horrid
code can be DELETED from X.

The problem with Xft and so on is that it is an "extension" only. They
should have written things so ALL applications got the same set of
anti-aliased fonts and all ran through the same new code at the bottom.
This could be done by changing Xlib to use the Xft interface. The legacy
system would not "fall into disuse", it would be DELETED IMMEDIATELY,
without breaking any existing programs.

As I have said several times, the X developers should be ASHAMED of the
fact that MicroSoft managed to change their GDI32 interface to use
anti-aliased fonts in a way that all programs could use them without
being rewritten, yet they could not do the same feat.

Time for X12?

Posted Apr 4, 2003 13:54 UTC (Fri) by jamesh (subscriber, #1159) [Link]

If it didn't break backward compatibility, it wouldn't be X12. The fact that it is possible to build all the features people expect in a modern windowing system without breaking old apps is a _good_ thing.

There is nothing inherently bad about using X11 extensions -- you will probably find that all/almost all of the apps on your desktop are using at least one extension. They allow an application to query whether the X server supports a certain piece of functionality. If the extension is not available, the app can decide to either use some fallback code or simply die.

The extension mechanism is the reason that things like the RENDER extension to be added with minimal impact, and remove functionality that turned out not to be such a great idea (ever heard of the PEX, XIE or Zoid extensions? If not, that proves my point).

In your reply, you seem to have been mixing up interface and implementation quite often. As new functionality gets implemented in the X server, there is no reason why the implementation of the old interface has to stay around -- it could very well be reimplemented in terms of new code.

On the subject of fonts, it is true that the old core fonts API was inadequate which is why a new API needed to be developed. If the old API had been sufficient, then it probably _would_ have been updated (remember that the core X11 protocol is a fair bit older than GDI32). On the bright side, the font configuration portion of Xft (which is now in a separate library since Xft 2.0) is generic enough that it could be used to configure the selection of fonts available through the core protocol which would allow an administrator to configure the same set of fonts for both APIs.

Time for X12?

Posted Apr 3, 2003 18:59 UTC (Thu) by iabervon (subscriber, #722) [Link]

I agree with dropping visuals from the protocol (the library could tell you about your visual, if you asked, but you'd always get the same one). Just have 32-bit rgba colors with no indexing.

The old font interface should remain, since programs use it. Furthermore, the best fonts are really the non-anti-aliased bitmap fonts which were hand-crafted at the resolution you're using. It's just for applications which want a range of fonts, sizes, and effects that scaled anti-aliased fonts make sense. Of course, like the rest of the core protocol, the old font code should support blending when using a semi-transparent color.

Time for X12?

Posted Apr 4, 2003 13:40 UTC (Fri) by IkeTo (subscriber, #2122) [Link]

> best fonts are really the non-anti-aliased bitmap fonts
> which were hand-crafted at the resolution you're using.
> It's just for applications which want a range of fonts,
> sizes, and effects that scaled anti-aliased fonts make
> sense.

Definitely not the case. Antialiasing is needed whether or not your fonts are tuned to a particular number of pixels. It fixes one primary issue: the screen resolution is far from enough for human not to notice the artifacts. When the screen shows you a slash, you see a staircase instead. The problem is there unless your screen resolution is in the order of 1200dpi, which for a regular notebook screen it is something like 14000x10000 resolution. Until that kind of resolution becomes available at low cost, anti-aliasing reduces the problem by changing pixels that should be partially filled to a color partially black. The actual improvement is within the brain, not on the paper or any physical phenomenon. The brain process the greyscales into in indication that the character is smooth. If you enlarge it you'll find the character not as clear as a carefully engineered character, but at a reading distance you perceive a better quality character.

Even the printers use such techniques: larger and smaller dots at the edges and corners of the characters it prints improve dramatically the perceived beauty of the fonts. And we are talking about 600dpi there. Screen fonts are definitely not an exception.