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."
X is not *ugly* per se. Some of the window managers and themes are debatable.
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.
I'm guessing you're an ex (or current) Amiga user. This is how for so many years, despite inferior hardware, the Amiga managed to pull of some amazing graphics feats.
I seriously hope that the X team take your post _very_ seriously indeed.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
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?
/' to get some text in your window. Now play with the scrollbar. See what I mean? The buttons have their own logic, but it's highly conterintuitive, and they can't even agree with the rest of the world as to which side of the window it belongs on! Aren't you glad every scrollbar doesn't work that way?
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
Do you have a more detailed description on how you want this to work?
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.
--
Life's a bitch but somebody's gotta do it.
Why doesn't someone write X extensions for anti-aliasing and alpha? This sounds like an admirable short-term fix. Let XFree86 5.0 be a new system, until then lets have the modules. Anyone want to start some projects at sourceforge? (If I see no action on this I'll register one and provide links and what information I can; but I have to learn it first!)
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