A New Rendering Model For X 173
horst writes: "I found this proposal by Keith Packard at mosfet.org. a good article, very interesting." Although it's more than a month old, if you are interested in the state of X, how it got to be that way, and where it's likely to head next, this is essential reading. In fact, you'll practically have to read it to find out why Packard concludes that "[a] new rendering model, designed to solve
specific performance and network transparency issues of these new toolkits, has the promise of significantly increasing the power of the X desktop environment."
Re:Could be worse. Right on .... (Score:1)
Sure, the rendering performance of X can be greatly
improved and those who read the article the might instead
discuss some of the concrete suggestion made there.
X performs well for me on my home P200MMX with a cheap
on-board video card - I always run 16 bit color. It is not as
fast for games as "Direct X" but on the other hand allows
great flexibility and stability with multiple desktops - attempts
at this with Windows are ALWAYS buggy or flawed. I even
get decent performance with Mesa demos and some apps
without a 3d accelerator - of course not for heavy 3d games.
But, with a 3d accelerator you can get very good performance
with such games in LInux or other unixes with otherwise modest
hardware.
I used to be heavy into graphics and was an early user of
Amigas when PC had no graphics to speak of, but I am now
too old?? to get overly excited about ridiculously immature
games like Quake. I'd much rather play something like Angband
these days with NO graphics at all on a text mode terminal.
This is not about performance for the needs of most users,
even professional artists and designers. It's about bragging
rights in playing immature games for preteens on how many
frames per second one gets while splattering blood and guts
in imaginary scenarios.
You can have Direct X for Windows. It's a kludge, a horribly
ugly programming environment and is the one thing besides
the AOL/IE5 combo almost guaranteed to ruin multitasking on
Windows and bring the system down.
Hey, people are working to improve X and bring its built-in
rendering engine up to date. That's good news. Some
important technical issues were discussed in the article.
It is much more likely that such improvements will be made
than that Berlin or something similar will replace X on the
unix desktop. This effort needs support. - and I think it will
get some from the commercial unixes as well as from the
LInux oriented toolkit people (kde and gtk in particular).
Great!
Why Athena scrollbars suck (Score:1)
This explains why OpenLook had rather odd scrollbars too.
Re:X is the biggest problem for Linux (Score:1)
Re:X is my favorite whipping boy.. (Score:1)
X can be made to look any way you want it too look
It's not X its the toolkit
Every single toolkit is too ugly, therefore X is too ugly.
X is too slow.
Not over a network.
Its not slow, if you have good drivers for the card locally. Especially XFree86 4.0 More than adequate to get work done
DOWNTIME IS GOOD!!! IT GIVES THE SERVERS A REST
X is too old.
Unix is older. 1970.
Linux is older. It was discovered by the military in 1947, in Roswell, New Mexico.
X is bloated.
Name another protocol that works localy and over a network, that takes less ram.
Telnet. 'Nuff said.
X is dumb.
that's a very personal opinion.
But his is right.
X is stupid.
The proper response is no, you're stupid what's so stupid about x
He told you, but you weren't listening. This is an 'all of the above' type response.
X isn't GPLed.
I'm going to assume you mean XFree neither is sendmail or mozilla. there are alot of good non gpled projects. get your head out of your ass.
Only if you get your head out of his ass first. X was GPLed around the time that beta 0.6 came into being. It's just that Stallman never acknowledged that it was GPLed then, because he was working on his own pet project (which he later gave up on), a windowing system for Emacs.
X has a difficult user interface.
X has no user interface. X enables you to build whatever user interface your want on top of it.
No user interface is a bad user interface. 'Nuff said.
More PHP support would be nice. for HotGrits.Org ! (Score:1)
Hotgrits.Org. Free Speech (As in Trolling).
"Gritz" - Anonymous Coward. (Score: -1, Troll)
"Trollz" - Anonymous Coward. (Score: -1, Troll)
"Natalie Portmanz" - Anonymous Coward. (Score: -1, Troll)
"Linuxz" - CmdrTaco. (Score: 5, Funny)
Re:4 biggest problems (Score:1)
Re:How big a job would it be to migrate? (Score:1)
Re:great idea! (Score:1)
Re:Could be worse. Right on .... (Score:1)
Antialiasing? (Score:1)
But, is there a time-table for these changes? Has anyone even started coding this, or is all this really just pre-coding hype?
Alex Bischoff
---
Re:X uses only 16 bits... (Score:1)
You have to have negative coordinates sometimes. Otherwise, how are you going to represent windows that are partially off the top or left side of the screen?
X/Berlin; missing the point (Score:1)
X Terms are still used! (Score:1)
>Personally I like the idea of X as a dumb display device. At uni I actually use a X terminal, i.e. a fairly dumb device that connects to a server, they still exist and they still do a decent job. Something which makes the GUI nicer would be great though.
X Terms still have a use actually (Score:1)
The main reason why you would want a X terminal is likely for the first year students to use. =)
There is very little to break down, they take up almost no room, and basically they get the job done, a PC running as a X terminal on the other hand require far more maintance, more parts = more breakages.
I wonder why none has sold wireless X terminal yet.
Re:Now there's an idea . . . (Score:1)
John
Re:This is not science fiction (Score:1)
John
Re:Why X needs the boot... (Score:1)
John
Re:in other words (Score:1)
It's funny you should mention scroll bars. I have to use a Windows NT 4.0 box at work, and one of the things that drives me absolutely around the twist (apart from the random lockups) is the behaviour of Windows' scroll bars. They act like ordinary control widgets, and deactivate if you move the mouse too far from them. In other words, if you want to scroll down you have to keep the pointer within a few tens of pixels of the scroll bar in the X direction, or the thumb pops back up to where you started scrolling! Argh! Why can't it just read the Y position?
Personally, I prefer the old Athena scroll bars, as seen in XTerm, with the left/right click to move down/up by different amounts and the middle button to free scroll. I get the impression you're talking about the *look* of the scroll bars, rather than the functionality when you say `how about putting in GTK scrollbars everywhere' (paraphrase) -- this is modifiable by third-party libraries such as Xaw3D [best.com] -- scroll down the page to see more alternative sets. These changes can be made without recoding applications!
In order to use GTK code changes would be required to all applications with scrollbars. This would be a nightmare, and besides, GTK doesn't have X resources so you can't so easily modify widget behaviour.
It's a shame that X didn't provide an attractive widget set in the first place (or, alternatively, that Motif was, and is, so expensive). Motif, with its rich configuratbility via resources seems cleaner to me in many ways thatn GTK. I presume this will be fixed in later GTK releases, and I hope to see support for X resources at some point...
I've begun to ramble now, so I'll stop, but I'll just round off by saying that vanilla X is almost certainly more configurable than you're giving it credit for.
--
W.A.S.T.E.
Re:in other words (Score:1)
Which is quite a long physical distance if you run in 1600x1200, which I do...
...by which time you've lost your position in the text you're reading. Why can I not configure this bizarre behaviour?
Just because the functionality is there does not mean that you have to use it.
--
W.A.S.T.E.
Re:in other words (Score:1)
s/long distance/short distance/
Doh!
--
W.A.S.T.E.
Clarification: (Score:1)
Win98 produces acceptable performance, but my Linux install produces superior results to Win98.
Re:Antialiasing? (Score:1)
These could be implemented as extensions...although this would increase the bloat that we giddily know as X.
Re: How would this work (Score:1)
Client-side fonts and high resolutions (Score:1)
You bring up valid points (Score:1)
bring up, like the ugly security model X has,
or a number of other things. But the point that
I'm trying to make is that while X certainly
has its failures, it also has achieved a number
of really useful things that other living
windowing systems lack. Network display,
flexibility (things like ssh's X redirection magic
and such being possible testify to this),
proper segmentation (so different window managers,
graphical logins, etc are possible), possibility
of X Terminals, etc. Someone replacing X has
pretty high expectations to satisfy.
Re:Something I always thought would be interesting (Score:1)
Re:Why Athena scrollbars suck (Score:1)
I believe the odd behavior of the buttons is because there are no arrows on the scrollbars and they used two mouse buttons to click them up and down. It is also possible that the Lisp machines in use at MIT did this (I do remember they had scrollbars). Somehow the line up/down got mutated to page up/down, this was later and possibly in response to the Mac's page up/down. I would say that those scrollbars were about the worst possible example of user-unintuitivity and it seems hard to believe they still remain (but they do, in Emacs...)
Xt is in fact a horrid mess itself, about 50% responsible for the disasters in Motif. For this reason I totally disagree with people who say a widget-framework should have been built into X. Such a framework would have been some horrid bad design like Xt and we would be forced to use it! X's innovation is not that it is well designed, but that the designers had the sense and humility to realize that perhaps some stuff could be done by the application!
Re:This is not science fiction (Score:1)
Lets not confuse representation with implementation. OpenGL can "represent" all of the features we want, but perhaps doesn't "implement" them all well. I think Berlin made the right choice when they realized they could choose anything which allowed representation of concepts they needed after all the optimized implementations will come later.
Arguments about what in OpenGL can be accelerated applies to both this new standard and the old, and thus are meaningless in the context here. OpenGL supports concept of antialiasing. Only some hardware supports it. This will be true regardless of what protocol the data is sent in.
You can skip the current OpenGL implementation, but skipping the conceptual parts that OpenGL presents seems off. OpenGL is also extendable thus such thinks as a better 2d transparency or font model could be added without need of fresh start. This would make for a more consistant platform overall.
--Karl
Could be worse. (Score:1)
When he mentioned KDE and GNOME, it made me think that maybe his underlying motive for improving X rendering was to make those funky waves that Enligtenment will put on the bottom of the screen work better.
X uses only 16 bits... (Score:1)
32768 x 32768 ought to be enough for anyone!
Re:in other words (Score:1)
I really prefer Athena scroll bars. Depending on where and which button you click you scroll back (or forward) some amount.
You don't have to reposition your pointer when the slider slides past your pointer, just keep clicking the same button and continue. If you only want to scroll a little, click near the middle. Want to scroll a lot? Click near the end.
Want to move instantly to a position in the scroll back? Middle click there. No more having to hit the slider and drag it.
IMO, Mac/Windows scroll bars are crude compared to Athena bars. Just because they look better doesn't mean they're more useful.
I guess this is why X, like the kernel, doesn't try to enforce policy. I like my scrollbars different!
Other Unix boxes X (Score:1)
to the default X version? IE are we
going to see them on other Unix boxes?
Re:The Amiga and LSD (Score:1)
Re:X is the biggest problem for Linux (Score:1)
I tried reading the full set of doc's on X once.. I only understood about half and oooh did my head hurt. That was several thousand pages.
Re:X is my favorite whipping boy.. (Score:1)
Check out Blackbox [alug.org] if you want to find an incredibly fast, efficient, and well coded window manager.
Will changing it break anything? (Score:1)
Still, it would be nice to run other resolutions within a window, (breakage or not!
As per the comment that "X is not GPL'ed" I don't know if a new version should be. Rather I think that a BSD style licence or (rather like apache) it could have both licences. X is not totally closed AFAIK (you have to be on the list to see the code) and I don't know how many graphics card makers would be forthcoming with the code if its fully open.
Then again, everyone (except nVidia Booo!) seems to be going open anyhow...
I think that the licence on a new version is an interesting issue.
Re:X uses only 16 bits... (Score:1)
This could be far larger than 32768^2, but would be convenient to represent as screen-relevant 2D coordinates for the benefit of simplicity.
Beware the competition (Score:1)
The paper notes the increasing dominance of newer toolkits like gtk and Qt, and the fact that they can make migration to X-NextGen easier. On the other hand, they could also make abandonment of X viable. This soul-searching may well reflect an awareness that alternatives loom in the still-distant horizon.
Troll Tech has already announced [newsalert.com] Qt/Embedded: this allows Qt apps to run without X, using Linux's framebuffer. It offers anti-aliased text and alpha-blending of images, as well as hardware acceleration. Imagine a Gtk/Qt system that can share the framebuffer and bypass X. You could get a lot done with the latest generation of apps, faster, and with less memory.
Re:X is my favorite whipping boy.. (Score:1)
It's about time. (Score:1)
I only wonder that when they're done with it, whether it will be fair to call it X anymore, or if it'll need a zippier name than X12R1
Re:Something I always thought would be interesting (Score:2)
And no, java isn't even remotely perfect. There is way too much extra shit in java. Postscript is a much better fit to this problem.
Postscript is not a good fit to any problem (Score:2)
And Postscript has *way* too much extra shit in it. Java doesn't have "save/restore", for example, which was always madness and looks madder than ever when looking at interactive stuff.
Java is certainly the right fit for this problem. I agree that this would be very desirable. Not Swing or whatever, just the core Java language combined with a rendering model designed for this problem.
--
Re:Something I always thought would be interesting (Score:2)
John
Re:X is the biggest problem for Linux (Score:2)
Erm...I remember someone saying once that the toolkit GTK would NEVER become popular because:
1) there were already a number of toolkits "out there"
2) there was only one app that used it (GIMP)
And now look.
The moral: Berlin probably won't become popular because many folks will say, "Gee, why code for it? There aren't any apps yet." It's kinda like Catch-22: You can leave the army if you can prove you're crazy; however, if you can prove it, you must be sane.
The problem with attempting to improve on X (Score:2)
perfect, but there are so many things that it does
right over its surviving competitors (e.g. the
Windows GUI) that improving on it will be very
difficult. There are so many important features
of X that people who try to write a replacement
would be tempted to take out to make the ship
date sooner that it seems unlikely to me that
a replacement will come along soon.
Re:This is not science fiction (Score:2)
A whole lot of comments. (Score:2)
comments on it. I have worked with X a great deal myself, writing 2-D
graphics manipulation programs at Digital Domain, large amounts of GUI
code, and a toolkit (www.fltk.org). I would be willing to help out
with coding or ideas or anything, as I see the replacement of the bad
parts of X as being vital to the future of it.
Certainly we NEED to replace the X rendering engine and this goes a
long way. I also don't think any replacement will be accepted unless
it is possible to emulate the old system atop the new one, and to
emulate the new one (slowly) atop the old one, so that a gradual
transition is possible. Adding things to the X protocol looks like
the only way to do this.
I don't like the fact that you seem to be concerned with moving the
minimal amount of drawing code to the server. I think this is wrong:
I want the server to do absolutely as much as possible. We have no
idea what may be hardware-accelerated in the future. I am also tired
of trying to use a bunch of shared library which don't understand each
other and don't cooperate to draw things.
COLOR VALUES:
I disagree with your desire to keep the pixel values and the raster
ops visible. These are not needed for any modern graphics system,
based on the stencil+fill model. I am also afraid that if they are
not gotten rid of completely it will greately decrease performance.
On all hardware I would like to see colors directly specified (at
least with 32 bit rgba numbers, perhaps other ways). The driver
figures out how to represent these on the hardware. I do not believe
the translation is that expensive: it is certainly cheaper for the
server to do this translation because it has ONE target format, rather
than having the application do it to a arbitrary target specified by
the server.
8-bit hardware colormaps can be filled and the closest available color
used when the map is full. This is the solution used by all toolkits
today and I see no problem with moving this to the server. Filling
colormaps is one of the big round-trip time wasters with X. If we
added one more call indicating "I don't want this color anymore" then
colormap cells can be reused without closing the connection.
For emulating old xlib programs I would have the interface claim that
only a TrueColor visual is available with 8 bits of r,g,b. This will
allow the deletion of all the old colormap stuff from the X server and
allow great freedom in the new implementation. Programs that cannot
use TrueColor are not going to be supported (this is already true for
XFree86 in 16/32 bit mode so I don't see this as being a problem).
The only useful "raster op" is "XOR" and that is only useful for
drawing "overlays". Exposing this prevents the server from taking
advantage of real overlay hardware. I would prefer to have "draw in
overlay" and "erase from overlay" added to the gc. On simple hardware
these both do XOR. On more advanced hardware the overlay is used, and
maybe the current color.
ALPHA COMPOSITING:
It may be important to support "premultiplied" alpha compositing,
which is A+(1-alpha)*B. This form of image is often generated by 3-D
rendering programs. The non-premultiplied version is actually better
but the premultiplied form is so common that it must be supported.
I would also like to see non-premultiplied alpha "paint", ie you can
set the current foreground color to have alpha. This does not need
hardware acceleration but should be in the server.
Far better antialiasing can be achieved by taking into account the
actual brightness of pixels on the screen (the screen gamma). The
proper way to add screen colors is (A**(1/g)*alpha+B**(1/g)*(1-alpha))**g,
where g is the screen gamma (approximately 2). I think this can be
done with a lookup table?
COORDINATE SYSTEM:
I think you *should* use IEEE 32-bit numbers and put the
"transformation" into the server. You must support Inf and not crash
when NaN are passed in.
Using floating point is the only way I see to avoid having two
clipping bottlenecks (one in the program to clip to the legal
coordinate system and another in the server). Clipping is NOT as
cheap as you said, as it involves calculating a new path by
intersecting the lines with the edges of the clip area.
Having the transformation in the server is necessary for supporting
font rasterizers and to take advantage of hardware acceleration for
transforming images.
The translation inaccuracy problems you mentioned are eliminated by
having a current transformation, if you seperate the current
transformation into an integer translate and a fp matrix. The program
can then translate so that 0,0 is on the screen and draw with very
high accuracy.
It is not necessary to have a transformation stack, just setting the
current transformation directly would be sufficient. However I would
not complain if there was a stack.
PATHS:
I do think paths should be in the server, because otherwise people
will write wrapper libraries that will be slower than doing it in the
server. Like PostScript, paths are built using the current
transformation, they do not move when you change transformation. This
allows them to be converted immediately into trapazoids.
Characters may be drawn into the path. Since these are antialiased
bitmaps from the font renderer this means the path must support
antialiased bitmaps. Also current X supports the ability to add 1-bit
masks to the clip and it seems likely you will have to support this
for back compatability. Therefore it seems likely that the path must
be an arbitrary gray-shade image (internally stored much more
efficiently as a combination of images and trapazoids). This is a
pain but I see no way around it.
Unlike PostScript you can probably require the program to say what it
is going to do with the path before it builds it. "Stroke" for
instance would be totally different and could ignore bitmaps (or draw
a box around them).
"Fill" would fill the path. It may help to insert some OpenGL into
here and allow the color to change as the path is built and it then
did Gourand shading of the path.
"Clip" would use the path to set the clipping area, intersecting it
with the current clip.
It would be real nice if a window could be created with the current
path, to replace the "shape extension".
TEXT:
I do not want the Windoze-style 12-parameter call to sepecify a font,
and I am afraid this is what you are suggesting. I recommend a call
much like this: setfont(gc, const char* name, int attributes, float size).
The "name" should be something that we are willing to show a user,
like "Helvetica". The attributes are bitflags for bold, italic, etc,
but in all cases the same attributes may be achieved by adding "
Bold", " Italic", etc to the name and leaving the attribute zero. The
size is a convienence, as the current transformation should be used to
figure out the letter forms, the size temporarily scales the
tranformation by that factor, sets the font, and scales it back.
The PostScript model where the size is the true "point size" MUST be
used. This means the size is the minimum line spacing, not the ascent
size that has been popularized by broken Windoze and Qt. This is
necessary to typeopgraphy and for supporting non-Latin fonts.
Another pet peeve: can I PLEAD with you to support UTF-8 (and ONLY
UTF-8) encoding! This is a standard to translate 8-bit bytes into
Unicode indicies. I don't care if you draw a box for every Unicode
character not in the font, just support the $#$%@ encoding! I believe
there is NO need to support plain 8-bit or "wide" characters, but I
know others disagree. Illegal UTF-8 sequences (including characters
encoded longer than needed) should be represented by using the bytes
individually. Change Unicode by replacing 0x80-0xA0 with the
MicroSoft character set, because we must face the fact that they have
taken control of this standard.
Measuring text for layout is a problem. Any kind of character
metricies system prevents the server from doing intelligent kerning or
overprinting, it also requires the application to understand UTF-8,
which eliminates the whole point of UTF-8! Any other solution would
look like HTML, greately limit the amount of formatting control the
program has and being very complex. I think we have to give up on
eliminating the round trip and recommend instead that the gc have a
"current string". The program sets the string to an array of bytes
and then can request the metricies of how that string would be
formatted (ie the bounding box, etc). The program can then tell the
server to draw the string, or it can change the string by either
replacing it or truncating it to a substring. This at least
eliminates the need to send the string twice and lets the server cache
info it got when it measured the string.
IMAGES:
Again, I STRONGLY disagree with the conventional wisdom that the only
fast way to do images is to have the program know the details of the
hardware. Though true in theory, the pratical solution is to have an
ENORMOUS library that can translate all possible pixel formats the
program has to all possible ones that any server has. Doing this in
the server is MUCH simpler, since it only has one target format,
reducing the complexity from N^2 to N.
I would greatly limit the number of source formats to ones that are
needed by modern programs. This means ONLY these:
"native" : a single format the server likes, much like X is now.
1-bit black & white
8-bit gray level
8,8,8 full color RGB
8,8,8 full color BGR
8,8,8,8 full color with alpha non-premultiplied RGBA
8,8,8,8 full color with alpha non-premultiplied ABGR
8,8,8,8 full color with alpha premultiplied RGBA
8,8,8,8 full color with alpha premultiplied ABGR
Just so people won't scream about my color limitations, also support
8*2^n bits per color, though this can be done by skipping the
low-order bytes for now.
The recommended call is this (or a seperate call for each format):
draw_image(int format, const char* data, x,y,w,h,delta,linedelta)
x,y define a position in the current coordinate system for the
upper-left corner. w,h define the width & height of pixels to draw.
Delta is the data increment between pixels (this allows other pixel
data to be skipped, or the red channel to be drawn monochrome).
Linedelta is the data increment between lines, this allows arbitrary
subrectangles of an image to be drawn. Both delta and linedelta may
be negative to flip or rotate the image.
It may also be useful to send raw jpeg or png data to the server and
let it be decoded there. This has obvious benefits for a network, and
also eliminates another need for many programs to link in another
library.
OTHER FIXES TO X:
Make a new type of "gc" that includes the damn window! It is
ridiculous that we have to send both the window and gc to all the
calls. Deletion of the window id would also shorten the protocol (it
is vital that the window be changable with a setWindow call, the lack
of this makes the Win32 gc's nearly useless).
Add a call that can define a huge array of atoms with a single
protocol request and a single round trip. This along with the
elimination of colormaps would get rid of most of the startup delay of
X programs.
Fix the X protocol so there is a symbol sent when an application is
waiting for events (actually it would be sent by XFlush if the buffer
is not empty). This would allow servers to synchronize updates with
vertical retrace, do double buffering, and consolidate mouse events.
It would also allow synchonrization with the X window managers: one
real annoyance with X is that you cannot map a window and immediately
draw into it, this looks horrible to programmers used to Windoze and
almost certainly needs to be fixed before they will be willing to work
on X.
Re:This is not science fiction (Score:2)
--Karl
Re:What about Quartz/Aqua? (Score:2)
Yes, NEXTSTEP and OPENSTEP use Display PostScript. So does Mac OS X Server.
NEXTSTEP and OPENSTEP (hereafter NEXTSTEP) work much like X does: you can display applications running remotely on your screen. But both ends have to be running NEXTSTEP, and the applications have to be native NEXTSTEP applications. That is, you can't display a NEXTSTEP application on your Linux box running X, nor can you display an X client application on your NEXTSTEP machine (unless you're running an X server on that machine, of course).
Quartz no longer uses Display PostScript, as Adobe isn't interested in licensing it (at least not for a low enough price). Quartz is more like ``Display PDF'', and it incorporates much of the font and text support from the orphaned QuickDraw GX.
Also, Quartz is the imaging model; Aqua is the interface. Aqua needs Quartz, but Quartz doesn't need Aqua.
Re:in other words (Score:2)
I hate that too, and I've sometimes wondered whether it was a side effect of the Apple UI lawsuit... Microsoft would be seeking to distinguish its UI from Apple's to thrawt the copyright claim. Surely not even Microsoft's UI designers would intentionally design in such an annoying and distracting feature.
BTW, Apple's UI is also sensitive to the pointer's X location, but if the pointer wanders outside its "slop" zone, the scroll thumb simply freezes in place -- much friendlier that jumping back to the top of the scrollbar.
But simply tracking the Y position would seem to be both the simplest and most obvious thing to do.
--Jim
Re:New possibilities? (Score:2)
Although it might be helpful to get the advice of an HCI expert here, it's going to be of limited effect. Where an HCI pro could have real benefit is in the window manager and toolkit design, because that's where policy decisions are made.
Remember X's longstanding motto and design principle: "mechanism, not policy".
--Jim
Re:NeWS windowing system (Score:2)
Java is hardly a successor to NeWS. Yes, they have some similarities, and both represent attempts to move more application logic into the client machine. However, Java is a programming language, not a windowing system. Java depends on X11, NeWS was a competitor to X11. Calling Java a successor to NeWS is a fairly imaginative stretch.
Re:NeWS windowing system (Score:2)
That's true, but don't you think those bugs would have been fixed years ago if NeWS won in the marketplace instead of X11? (Early versions of X11 weren't bug-free either...)
great idea! (Score:2)
One thing I'm wondering about is whether this X11 extension could not be based very directly on a 2D OpenGL subset--it's an API that a lot of people have experience with, that is well documented, and that's already part of many X servers. It's just a suggestion, and it might end up being somewhat of a compromise, but it might also help with the widespread acceptance of such an extension, because it would be really easy for many toolkits and applications to start supporting much of it immediately.
Re:NeWS windowing system (Score:2)
I used NeWS for a while and found it has some serious problems when it came to reliability, isolation of different applications from one another, etc. Java addresses these issues.
The only thing that is really missing is network transparent C++ bindings to the Java toolkit. With SOAP, XML-RPC, or CORBA, that wouldn't be too hard.
Re:Why X needs the boot... (Score:2)
Re:Why X needs the boot... (Score:2)
I think that's throwing out the baby with the bathwater. A lot of the stuff that makes X11 complex (pixel accurate rendering, pixel value manipulation, network transparency, properties, security, etc.) is intrinsically complex. Most other systems don't even bother offering a similarly complete package. BeOS, MS Windows, MacOS, and NeXT Step all address some aspects of it, but they also cut a lot of corners so that they can be targetted well to their market niche. That makes them a lot simpler and easier to deal with, but it also means they are not as general. I like X11 because it covers so much ground.
As I understand the proposal, it would not replace the old imaging model. In fact, I think it shouldn't. Pixel accurate rendering and bitwise blit operations are still important today. The requirement for the new, additional imaging model has come about because of new uses, and the logical way is to address it with an X11 protocol extension.
Re:in other words (Score:2)
I've begun to ramble now, so I'll stop, but I'll just round off by saying that vanilla X is almost certainly more configurable than you're giving it credit for.
It probably is, but still:
I'm not saying that X, by itself, should have had a widget set. X's modularity is one of it's few truly good points. But what they should have thought to do is provide some kind of place to call the widgets-- i.e. a standard set of stub libraries or somesuch, where the application simply requests a widget of a certain abstract type, and whichever widget system is installed on the computer at the time handles the request. (i guess today we'd do that with some kind of XML, dunno how they'd have done it then..) I believe doing a similar thing to the open/save dialog boxes would seriously improve the *n?x experience.
The scroll bars were not meant as an example of something fundamentally wrong with X, just as an example of something that X users put up with for no apparent reason. Because even if it is somewhat configurable, you have to admit that the widgets in your average linux install are something of a mess, and certainly no better than mediocre. And yes, scrollbar appearance is a nitpick, but it's a pretty damn huge nitpick.
"configurability" isn't the issue-- just that the X people should have thought ahead enough to realize, y'know, at some point people are going to be designing widget systems. If they had thought to provide a nice little place for widgets to plug in we wouldn't have the problem now of having to totally recode everything in order to switch between Motif/Athena/GTK/Qt. Even if it wasn't their responsibility to have solved the problem ahead of time, the problem should have occurred to them.
I, too, am now rambling, so i shall stop.
Re: How would this work (Score:2)
Thus, to implement scrolling, rather than copying memory, you just said "change the bitplane pointers to display one line further down at this display coordinate (in fact AGA amigas also had 1/4 pixel positioning for sub-pixel super smooth scrolling.)
It's a quite different programming paradigm, and it's why the Amiga versions of all those old 2D games like Sensible soccer, lemmings, etc, all scroll much better on a 7MHz A500 than a 200Mhz Pentium, and it's why the Amiga [amiga.org], rebadged as the NewTek [newtek.com] Video Toaster was king of the mid-range video and animation world for years.
At one stage , a company called Phase 5 produced a Vaporware plan to produce an Amiga successor, in which every pixel could come from an arbitrary memory location.
As an aside, the amiga also had another custom subsystem, the blitter (Block Image Transfer) which shovelled rectangular areas around memory, somewhat like the 2D-acceleration that PC cards came up with some time later, and it did hw-accelerated line drawing and flood fill operations too.
The intersting thing was that the Copper, Blitter and CPU could all trigger CPU interrupts, the Copper could trigger the Blitter, the Blitter and CPU could operate on memory that stored CPU and Copper programs (the Amiga had a unified memory architecture). Thus, you could make really insane self-modifying programs, once you stepped outside the bounds of the operating system - which is why Amiga Demo coders came up with such wierd effects (well, that and the acid.)
Re:X is _THE_ whipping boy... (Score:2)
--JRZ
Re:some one needs to X this thread correctly (Score:2)
--
Xng must allow *audio* redirection too! (Score:2)
This is really not an option in today's multimedia world. If this isn't built into Xng, then machines that rely on X will fall further and further behind the competition. Note that this would require at a minimum, CD-quality audio from X client to X server, and ISDN-quality from X server to X client.
Real touchscreen support should also be in there - that means not just something that pretends to be a mouse, but something that provides the fundamentals required by gestural interfaces, perhaps with a set of gestural recognition primitives. (Which raises the question of whether or not X should include written character recognition as well - given Linux expected penetration into the embedded space, this can be done once well, or many times probably not so well.
Remember, good programmers write good code, great programmers steal (leverage somebody else's) good code. Xng should have good stuff to steal.
Re:Printing... (Score:2)
Wouldn't this rather require a separate X server for printing? I don't see why the computer I'm typing at should do any processing of a print job. It seems to me that that should be between the computer I'm running on (the X client) and the computer the printer is on.
It seems to me that this is the big advantage of the client server architecture of X. Why should every user have to upgrade the X server on their box just to use the printer?
Personally I like the idea of X as a dumb display device. Although antialiasing and alpha would be nice.
Re:This is not science fiction (Score:2)
Re:Yes yes yes... (Score:2)
Re:The Current State of X :) (Score:2)
Re:This is not science fiction (Score:2)
...and one more thing... (Score:2)
I'd like to add one additional request in the name of bandwidth reduction. Display lists. One of the more interesting things about NeWS (Sun's post-SunView windowing system based on PostScript) was its ability to be programmed. You could create a routine that could render a whole button with bevels and shading and whatnot as a single function call whereas in X it will typically take six or more protocol requests to get the same job done.
While full programmability ala NeWS is rife with potential problems, given just the ability to record a sequence of parameterized protocol requests and request playback would drastically reduce the bandwidth requirements and boost the performance of a lot of applications while having very little impact on memory use. I believe display lists were considered and discarded originally due to the requirement that X11 run in a terminal with very little memory (too little to hold much in the way of display lists). I've never appreciated that since the client-side fallback technique was always a viable option, but given the opportunity to extend the protocol I think this would be something to consider.
jim frost
Re:X uses only 16 bits... (Score:2)
I'm so glad to hear this (Score:2)
Re:X uses only 16 bits... (Score:2)
Hmmm, isn't that what a certain Bill Gates said about the 640 kB memory window of the old IBM PC's???
Remember, what seems fanciful now may soon be more than real later. Newer display mediums, for instance, with incredibly tiny pixels may come out, and/or the means of stacking many many monitors together, and/or other technologies that I'm not thinking of right now. Basically, this may be of a limit at some point.
Also, wouldn't it make more sense for use an unsigned 16-bit integer for the screen position, such that it would really be 65536 x 65536?
Why X needs the boot... (Score:2)
If we want to have all the spiffy extras like anti-aliasing and alpha-blended transparency, X is going to have to be adapted. In the long run, it may be better and more efficient to build a new architecture from the ground up to meet the need of things like advanced OpenGL and user interfaces. One of the things I admire about the BeOS team (OK, the *only* thing I really admire about BeOS) is their dedication to ending cruft. Eliminating the crufty X Windowing System would greatly aid the stability of Linux and make it more competitive against that other little OS from that little concern in the Pacific Northwest.
Now, having said that, I realize it's easier said than done. However, we have a clear roadmap of what this new system needs to do. This could be another way of showing how Open Source can meet technical challenges better than closed development methods. Yes, it's a daunting project, but one that could have some great benefits to the OSS community at large.
X (Score:2)
ahhh yes, those where the days. When 256 was "real color!"
Frankly I think that most of Xs problems today is that it knows it's own history to well.
___
What CDE doesn't seem to do (Score:2)
Of course the look and feel of the newer systems is still much nicer, and they're much more intuitive about various operations, so why bother?
Re:4 biggest problems (Score:2)
Well it's not nonexistant, but it is quite a mess (at least for scaleable fonts). Point taken, but that is exactly what this article is talking about work on.
> Cut and paste is a mess
How so? I personally like hilite-middle-click copying. d&d is an incompatible mess that needs some help from the Xlib level so that different toolkits could get along, but the X11 cut-buffers work quite well I think.
> On startup of FVWM, kde, whatever...
You need to talk to fvwm/kde/whatever about this feature. X has nothing to say about virtual desktops, which are a window-manager creationand as such are managed by the windowmanager.
> With the current X release, no way exists to specify the location of pop-up windows
You mean the x,y,height, width, and Zorder (force to be on top) windowmanager hints? If your windowmanager doesn't respect them, I think that's it's problem. certainly X provides a way to tell the WM that this window should be here, this size, and always on top (thus avoiding the problem of being 'hidden under other windows'. In any case, a modal window should block only the one app it relates to, so killing the offender should be quite simple.
> A global way of assigning keystrokes to all apps under X.
There is one and only one X keymap (handled by Xkbd extension and tweaked by xmodmap). There are lots of ill-behaved apps that can't agree on what should be in it, but this is an issue exposed by the cross-platform heritage of these apps, not an inherent X11 problem. GTK and QT have gone a long way toward fixing this, it's just a matter of getting legacy apps tuned up.
It sounds to me like you don't like your windowmanager, and are blaming X for it's problems (an easy enough confusion - most other platforms don't have the distinction between graphics API and window-policy that X does).
Ugly? Only if you use the default theme. (Score:2)
Every single toolkit is too ugly, therefore X is too ugly.
I'll give you that for Motif, but GTK and many WMs can be themed. If you don't like how your widgets look, go to themes.org [themes.org] and pick up a theme or two.
Not if they use a wrapper server. (Score:2)
If we move to a new X (as I think that we should) what are the odds that some programs depending on X will break?
There will probably be a new X11 server running as an X12 client, that translates X11 calls into X12 calls.
Doing the math... (Score:2)
One obvious coordinate representation is IEEE 32-bit floating point numbers. The 24 bit mantissa specified by IEEE would provide at least 8 bits of sub-pixel position within the 16-bit X coordinate space, and would be easy for applications to manage.
Ok, using floats sounds a little strange, but maybe everyone's FPU are fast now-a-days, and who cares about ever running on hand held devices for the forseeable future, as the protcol itself will require a FPU to run well.
However, it is desirable for objects to be translationally invariant. As objects move to larger coordinates, IEEE floats will slowly drop bits of sub-pixel position information.
This is true, but you'll have quite a large number of pixels until the 23 bits bits of the mantissa (the 24'th bit is always one) aren't representing much sub-pixel positioning info.
The next question is how many bits of fraction to use. Four is enough for most applications, but eight will suffice for all but the most particular uses.
If 4 bits will do, I'd think that 2^19 pixels is a lot more than will be needed for some time. Even if 300 dpi flat panels come about in several years, and you must have 8 bits for subpixel location, 2^15 pixels at 300 dpi is still 109 inches!!
Well, that's enough nit-picking for one posting.
Re:Yes yes yes... (Score:2)
Good engineering (albeit for an outdated requirement spec) is one of X's strong points.
X is _THE_ whipping boy... (Score:2)
I mean...motif on an older SGI is pretty fly. CDE on SUN boxes runs great...and those machines are using Display PostScript, which is slower than other models.
I want my windowing environment to respond NOW, when I press the mouse key...not after I do it...
Cheers,
C
For people who complain about X11... (Score:2)
Frankly, I think that MS is far behind Linux because they don't implement technology good enough. MS Windows users are where they get their money from, right? They deprived their userbase of certain technologies and implement them separately in each version of their operating system without spoiling the user with new features. That way, MS can brag about their product's new features! I've coutlessly heard already, "Pah! Pah! Look Pah! MS Windoze too-hundred-tousand had implmended synedric multie processin! waphooooo!" Along with, "eeeewwwww1!, phree hotmail 'n outook excess! 'cant wait to wun it!" I mean to say that MS is behind in the race, not Linux, not BSD, not Unix as a hole. Goodbye.(I am sniping a Micronics motherboard/w snd on eBay, using Lynx in about 5 xterms :o)
X is good, but its time for a revamp. (Score:2)
Nothing pisses me off more to see a windowing system highly dependent upon old school hardware techniques, when the majority of people are running something slightly more powerfull than my 2meg ATI mach64 I had until I bought a V3. (damn good card!)
I would compare it to software being written with 386 optimizations (or MMX) and completely ignoring all the new CPU instructions that would improve the speed of the software greatly.
There are always going to be a few people laging behind the crowd with thier hardware, they are called those with limited funds. But, why optimize everything to run well on thier machines and not take advantage of better hw if available.
I am convinced that the software development cycle is usually not taught correctly. Not nearly enough importance is placed on the idea of throwing what you have away when your feature set far excedes the features of the system it was engineered for. There is no reason to completely scratch everything, but much needs to be completely redesigned with the "new shit" (tm) that has come to light.
If we don't do that now, we'll be stuck with the same historic problems microsoft and others suffer from by having too much hacked together code to start over, yet too much hacked together code to continue adding features.
Slashdot needs to allow me to use ispell on my comments...
Re:X is my favorite whipping boy.. (Score:3)
However, the lack of anti-aliased fonts IS ugly. I know most programmers/sysadmins/"hackers" don't care, but too many web pages and word processing documents look like Commodore 64 screen captures.
I've never experienced "slowness" in X that couldn't be corrected by switching to a different window manager. Do KDE or GNOME run well on my 486? No. Should they? Perhaps. Does WinNT run on them? Absolutely not. In general, I think GUIs have gotten way too "heavy" these days. It's funny -- I hear more and more people wishing their desktops could be more like their Palm, not the other way around. We've had a lot of "do-everything-but-brush-your-teeth" GUIs, maybe minimalist interfaces are the wave of the future.
All the other gripes are, as you implied, pretty lame.
Re:This is not science fiction (Score:3)
I seriously hope that the X team take your post _very_ seriously indeed.
Re:in other words (Score:3)
That would be a mistake. The designers of X wisely adopted a philosophy of "presentation, not policy" which meant basically that you could draw your scrollbars any way you wanted to, and X would allow it. Policy was layered on top of the window system in the window manager and in toolkits -- of which there are many today, including Athena, Motif, Qt, and GTK.
If the X designers had chosen to make policy part of the windowing system, then the only scrollbar today would be the Athena scrollbar. You think Motif scrollbars are bad? Have you tried an Athena scrollbar? Run an xterm. Not one of those new xterm-like programs but a real vintage xterm. Turn on the scrollbar. Run 'ls -lR
Some people have said that separating presentation from policy has led to mass confusion as the many different window managers and toolkits have tried to compete for acceptance with users and developers. Personally, I think that the abundance of WMs and toolkits have been a good thing, because it's meant choice for us, the users of X. Why should I have to use mwm or olwm when I much prefer Window Maker? Dictating policy and taking away choice is a hallmark of proprietary systems like Windows; X shouldn't try the same thing.
--Jim
Re: How would this work (Score:3)
A good place to start is Newman & Sproul, Principals of Interactive Graphics - check out the section on scanline rendering. The Quake articles written by Michael Abrash are an excellent source, and they go into a lot of useful detail (some but not all of which is only relevant to 3D) To answer somebody else's question, no I'm not an Amiga user but this is just the obvious way to do it. And the corollary is, check out exactly how it was done on the Amiga (I haven't, I'm curious). If the shoe fits, wear it.
Does it increase the amount of memory needed by the server?
No. One of the nice things about scanline renderers is how little memory they use. Of course you can add buffering as an accelerator depending on how much memory happens to be available.
Does it increase the amount of network traffic needed?
It would have no impact on that: exactly the same render commands are sent by the applications. The only extra traffic would be for animation programs synchronizing with the refresh, and that would be miniscule.
How would it cope with for example a Netscape window that was 500 pixels by 100 thousand, which you wanted to scroll smoothly through?
The same way it does now: send a command to scroll the part that doesn't change, clear and redraw the part that does, run the part that goes off the screen into a memory buffer as memory permits. The thing is, all of the transfers to the screen actions would be delayed until the Netscape program says "go ahead and do it". Then all the renders are done, optionally deffering rendering for regions that are not visible, but retaining the commands in case they become visible, (so you don't have to ask the app to regen the region). When it's time to update the screen, you do one of two things depending on whether you have hardware accel or not. With hardware the renderer does a scroll blit and a put blit for the browser window, or multiple scrolls and blits if the window is broken up, but only for the regions actually visible. Without hardware you work your way down the region a line at a time doing the minimal thing to each line, which may be copying it from another part of the screen (slow) copying it from previously buffered data, or putting it from the new render region.
It's also nice to be able to work in an unbuffered mode where all drawing is direct to the screen and the renderer clips each primitive as it's drawn. Needless to say this is much slower and you get flickering, and implementing such clipping primitives efficiently and accurately is hard. But it's very helpful so you can see exactly what your program was doing when it crashed, or exactly why you're getting a messy blob when you should be getting a nice web page. Running the render in slo-mo gives you a graphics debugger.
I've never actually done all this (except in 3D rendering code) so I probably missed a few important points, but I think this is the general idea.
To put all this in perspective, run xpenguins or xroach and notice how much the rendering sucks, and think about what you could do about that.
--
Now there's an idea . . . (Score:3)
Printing... (Score:4)
What you notice is that the screen rendering system is integrated with the printing system so that, at least in Windows langauge, the printer is 'simply another device context to write to'.
It is crucial that the printing of documents, image, etc. to a hardcopy device is not left as an afterthought as it was with X. It should be simple for an application to say `print these to such-and-such a printer'. This requires that an X server have knowledge of other output devices besides itself, but this is not so stupid an idea. (The idea of X as a dumb display device should be consigned to its rightful place in the nearest dustbin).
John
NeWS windowing system (Score:4)
I think I still have my treasured copy of the NeWS reference manual buried in a box someplace. Even now, over a decade later, X11 lacks features NeWS had, as documented by the article referenced from this Slashdot story. NeWS isn't commercially viable and hasn't been for many years; I wonder if Sun could be convinced to release the source code to it and see what could be done with in the Open Source world? (Nah, they'd insist on that abominable SCSL license...)
in other words (Score:4)
now where have i heard that before [microsoft.com].
(note to people about to flame me: not that X is _bad_, just that it's one of the few things i'm aware of in the linux/unix world where something is in hugely wide use because of inertia and no other reason without any serious attempts at alternatives. (yeh, yeh, berlin, whatever) Yes, X is good enough, and the idea is nifty, but i have no idea why people put up with the fundamental shortcomings X does have so easily when these tend to be the people who in other circumstances demand the best they can get, and if they can't get it, write an alternative. Like, the scrollbars. Linux scrollbars are almost invariably hideous, probably as a result of the motif disease which infects everything. That's a tiny thing, but pervasive, and nobody ever bothers doing anything about it. And yes, i realize the scrollbars aren't handled by X or the WM. I don't care. Would it be that difficult to go and _make_ it so they are? would it be that difficult to make a concerted effort to go look at all the standard X progs you're likely to use and jam in GTK scrollbars? Why does nobody bother caring about these things in X? I'm too tired to explain these comments in detail or give examples, so i'm going to get flamed to hell and back. But i could go into greater detail and explain such things if i felt like it. And the article gives a great deal of examples of things in X-- fundamental things-- which are clearly no better than barely acceptable but nobody cares about. So go read that. And i'd add some to the list, such as having a "move this rectangle on the screen over ten pixels" type function that worked, preferably in the xserver's processing, but i dont feel like looking up and checking to make sure x doesn't do such things acceptably already.
The point is, X works, but you could have something so much better if "the community" just tried. But it won't. Well, let's hope Berlin actually gets somewhere. whatever, i'm going to bed. What was NeWS?)
Re:This is not science fiction (Score:4)
- The performance on typical hardware can often be improved by giving it more attention in the driver. However, there is a fundamental problem here: the framebuffer resides across a slow bus (PCI or AGP), so you really don't want to push pixels one by one across it.
- Using e.g. textured quads and OpenGL's wonderful blending [sgi.com], alpha testing [sgi.com], and stenciling [sgi.com] modes to express operations is not a nasty trick. If you want to blend two images together, being able to express that at polygon level rather than through tight CPU loops is elegant, not nasty! Also, it conserves bus traffic like crazy, and makes better use of the hardware on your graphics card.
- Doing graphics operations pixel-by-pixel using the host CPU is simply not what today's graphics boards (and machines) are optimized for. This might change in the future, but currently you have tens of millions of transistors in your graphic card's "GPU", so why not use them?
The last point above, that graphics operations today are best performed in very close vicinity to the actual graphics board, is basically what the linked article was about: moving functionality into the X display server makes it possible to execute it on the display hardware directly. This, in my opinion, is a very good thing.X is the biggest problem for Linux (Score:4)
Yes yes yes... (Score:4)
So go code a solution. All I've been hearing is talk.
The Current State of X :) (Score:4)
What about Quartz/Aqua? (Score:4)
It's true that X is way out of date and needs to be improved. However, why should we settle for a few small additions (like cubic splines and transparency) to barely catch us up to today's technology? We discussed Aqua/Quartz [slashdot.org], the new graphics technology developed by Apple (if you haven't read about it already, it's radically different than any existing system) and maybe we should all be moving towards something more like that.
Someone posted a concern that a new system would break existing X programs - but I doubt that would be a problem - if we switch to something new (and more powerful) we would just need wrappers that support the X11 API. I'm all for it.
Something I always thought would be interesting... (Score:4)
Back in the days when I did a lot of Motif development, I always thought that the biggest flaw in X was how simple type-in fields worked. It seemed like such a waste of network traffic and server (or client in X11 lingo) processing when all you were doing was typing in a field. This is primarily what makes X11 unsuitable over the Internet.
What I was thinking would be really cool is to embed a Java engine in X terminals, and allow Java-based widgets to be downloaded. Imagine if this was in the core X11 protocol, and it was a very general object interface. You do all sorts of very cool -- very network efficient -- things.
Note that this doesn't break the X11 concept of "presentation, not policy". Policy would still come from the client program. The Java widgets would still be tied to the client program.
Java is not everyone's favorite language, but I think this is exactly the sort of thing that Java would be perfect for, particularly the platform-independent nature.
--
Berlin (Score:5)
I'd love to see X speed up and keep up with the times, but I'm kinda afraid that the code may be too entrenched to make any serious structural modifications to this. I'm not an XFree hacker, so I don't know how much code modification what this guy is proposing would *really* take.
I do know that X works pretty well right now, and in the past, X people haven't been too willing to break the thousands of applications that are out there, even if it was The Right Thing To Do as far as architecture is concerned.
Re:This is not science fiction (Score:5)
I'd like to add a suggestion. 2D rendering is best done much like 3D software rendering: with something like a scanline renderer that makes one pass from top to bottom to render each frame, rendering exactly what needs to be rendered and no more. Instead of depth you have window priorities. Unlike a 3D animation renderer, you optimize for the fact that most of the screen doesn't change at all (so, to respond to another poster's remark - OpenGL isn't the way to go for 2D rendering - it carries too much overhead with it.)
Applications can know or not know about this frame-oriented rendering. If they know about it then can do really smooth animation by synching their erase/redraw cycle with the rendering cycle.
Advantages to be gained are: Software cursors that don't flicker; animation that doesn't flicker; video windows that don't exhibit strange behavior when you drag other windows across them; Scrolling windows that don't have little flickery blank spots at the top/bottom. And you get way, way more possibilities for optimization.
And don't forget this principal: when it's all done it should be smaller and tighter than X is now, even while doing 5 times as much. Because we had time to think about it and factor it correctly.
--
Re:X is my favorite whipping boy.. (Score:5)
X can be made to look any way you want it too look
It's not X its the toolkit
X is too slow.
Not over a network.
Its not slow, if you have good drivers for the
card locally. Especially XFree86 4.0
More than adequate to get work done
X is too old.
Unix is older. 1970.
X is bloated.
Name another protocol that works localy and over
a network, that takes less ram.
X is dumb.
that's a very personal opinion
X is stupid.
The proper response is no, you're stupid
what's so stupid about x
X isn't GPLed.
I'm going to assume you mean XFree
neither is sendmail or mozilla. there are alot of good non gpled projects. get your head out of your ass.
X has a difficult user interface.
X has no user interface. X enables you to build whatever user interface your want on top of it.
This is not science fiction (Score:5)
SuSE is paying me to specify and implement this stuff. I'll have some demonstrations to show soon.
Nothing in this proposal will affect the way existing applications operate; X provides an extension mechanism which will be used for new functionality. Yes, this means that apps will need to change to get new functionality. Compatability bites.
This paper is being published as a part of the proceedings for this summers Usenix conference where I'll present a nice talk on the subject. They've requested that I make sure you all know who's publishing this.
Keith Packard
XFree86 Core Team, SuSE Inc.
keithp@xfree86.org