LWN: Comments on "A discussion with Keith Packard"

Teleconference minutes

jamesh — Fri, 04 Apr 2003 13:57:38 +0000

The teleconference minutes were published on the forum list:

http://www.xfree86.org/pipermail/forum/2003-April/001014.html

Time for X12?

jamesh — Fri, 04 Apr 2003 13:54:34 +0000

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?

IkeTo — Fri, 04 Apr 2003 13:40:31 +0000

> 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.

Most inportant development priority

tino16582 — Fri, 04 Apr 2003 03:29:27 +0000

"The highest priority should be to create an environment where people are encouraged to participate to whatever extent they are able, and where these contributors feel ownership of their code and pride in the community in which they work."

I fullheartedly agree with Keith that the main priority with such a large and hugely important project is to first have the development process/community-issue sorted out. Otherwise the development will not scale with the increasing size and importance of this project.

Keith's comment on this issue really shows his commitment to the X project, defying those
people who depict him as just another person with a big ego.

--Tino Meinen

Traditional environments

melauer — Fri, 04 Apr 2003 00:01:46 +0000

>> One obvious first step is for X developers to start using
>> modern applications; many key X developers wear the badge
>> of 'twm' or 'fvwm' with pride.
>
>What's wrong with those? I also do not like these "modern"
>applications. I use tvtwm because it works the way I work.
[snip]
>The real problem is that they aren't letting new developers
>who prefer KDE or GNOME to participate. They should have
>a say just as the users/developers of the "old" interfaces.

I think the point is not so much that new developers aren't allowed as much input, but that there are too few developers who are familiar with modern Window Managers.

More generally, the claim here is that core XFree86 developers aren't familiar with the _applications_ which are running on XFree86 nowadays, the most important of which being the Window Manager. Even moreso for full fledged Windowing Environments like KDE/GNOME, which are supposed to be standards to which applications are coded. Knowing what users are trying to do with your software is a major clue as to where future development should lead. Perhaps too many XFree86 developers don't have that particular clue? Perhaps some XFree86 developers have no idea what other developers have had to add to their own code in order to achieve functionality which should probably exist in XFree86? I think that's what is being suggested here.

Time for X12?

spitzak — Thu, 03 Apr 2003 21:47:20 +0000

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.

Traditional environments

Ross — Thu, 03 Apr 2003 21:31:11 +0000

> One obvious first step is for X developers to start using
> modern applications; many key X developers wear the badge
> of 'twm' or 'fvwm' with pride.

What's wrong with those? I also do not like these "modern"
applications. I use tvtwm because it works the way I work.
X is nice because it lets people choose different environments.
That's why we can have GNOME and KDE. Telling people to use a
specific desktop because it is modern is not compatible with
that model.

The real problem is that they aren't letting new developers
who prefer KDE or GNOME to participate. They should have
a say just as the users/developers of the "old" interfaces.

Time for X12?

iabervon — Thu, 03 Apr 2003 18:59:56 +0000

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.

A discussion with Keith Packard

Baylink — Thu, 03 Apr 2003 17:20:08 +0000

For what it's worth -- and I've been active on the net since about 1984 -- I thought this was a very good interview, and it doesn't seem at all to paint Keith as a whack-job, as some people are suggesting.

I especially liked "a success catastrophe"; I think that's a delightful capsulization of a fairly common problem -- and as long as X has been around, I believe he's right: it hasn't reached the tipping point climbing it's popularity curve yet.. at least, not on a *consumer* scale.

For all that we like to rave about Micro$oft, it's well to remember that there are over *100 million* copies of various Windows based OSen out there -- it's not *quite* as bad as we give it credit for. Will X scale to 100 million copies?

Not if the development process is what he says it is.

There's a common error that's made in management, and makes itself in projects like this: assuming that someone who is good at X will be good at *managing* X.

This is rarely true; management is a different skillset almost entirely.

In most cases, it's just the joy of X that makes people do it; this doesn't transfer well to management tasks.

But who knows; I could be wrong; maybe it's just me.

So many things are just me.

Time for X12?

jamesh — Thu, 03 Apr 2003 14:47:11 +0000

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?

MathFox — Thu, 03 Apr 2003 09:50:23 +0000

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

A discussion with Keith Packard

james — Thu, 03 Apr 2003 09:11:28 +0000

With the current trend of Linux gaining a dominant voice, don't you think that a community driven development process could favor Linux up to the point that other OSes support becomes of inferior quality?

It's possible—but unlikely. It's been my experience that the Free Software/Open Source communities are extremely good at supporting the interests of other platforms, much more so than companies. Take, for example, the range of Unices that most prominent open source packages support, or the range of obsolete platforms that Linux or NetBSD work with.

I suspect that this is partly because most hackers find themselves in a "minority group" compared to Windows too often. It's largely because hackers believe that they should write to standards, therefore failure to cope with standards-compliant implementations is a bug. And it's partly because very few hackers started with Linux and have stayed there. Most still remember with affection their old SysV / Sun / Amiga / Mac / Atari / (whatever) systems. They're likely to view a 68030 with 6 MB of RAM with a certain amount of respect, not for what it is now, but because they remember that it once was a very desirable system.

End ESR mode.

A discussion with Keith Packard

ortalo — Thu, 03 Apr 2003 08:06:52 +0000

IMHO, a major achievement of the XFree86 project is the fact that
they support multiple operating systems, not only Linux (and this is
not so straightforward for a piece of software that directly deals
with critical *hardware*).
With the current trend of Linux gaining a dominant voice, don't you
think that a community driven development process could favor Linux
up to the point that other OSes support becomes of inferior quality?

Rodolphe