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