Slashdot Mirror
A New Rendering Model For X
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."
Look at both Windows (GDI) and the old Postscript based systems. In fact look at the new system deployed in MacOS X.
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
John_Chalisque
I used NeWS when it was first released. It was a wonderful windowing system, very flexible and powerful. I saw at the time (1988?) that Sun was making an enormous mistake in withholding the source code to NeWS when X11 was freely available. Couple that with the fact that Sun did a lousy job of supporting their own product (they didn't release applications for NeWS, for example), it's no surprise that X11 clobbered NeWS in the marketplace.
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...)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
X has a level of "acceptable mediocrity".
now where have i heard that before.
(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?)
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
- 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, alpha testing, and stenciling 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.main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
Shine on, you crazy diamond.
So go code a solution. All I've been hearing is talk.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I believe this site summarizes the complaints against X (and a few other things) fairly well. There's a chapter on the X-windows disaster available in full-text. Even if some of it's claims are overexaggerated, it is still extremely amusing reading.
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, 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.
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.
--
Sometimes it's best to just let stupid people be stupid.
AFAIK, this is one of the reasons Berlin started in the first place.
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.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
I made a quick scan through your paper and it all looks right on the money. We need alpha; we need rotation; we needed zoomable/scalable/rotatable everthing.
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.
--
Life's a bitch but somebody's gotta do it.
'X is too ugly.'
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.
It has been statistically shown that helmets increase the risk of head injury.
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