Slashdot Mirror
Xfree86 4.2.0 Out
According to david_eliasson,
Xfree86 v4.2.0 is out, but it'll probably be awhile before all
the mirror sites have sycned up with the release, so you may want
to just enjoy reading that changelog for a couple days before you
bother getting the whole archive.
Here's a question that I want to address carefully, because it does sound a bit like flamebait.
Should the Unix/Linux world move away from X? Redesign a graphical layer from the ground up, supporting antialiasing, transparency, enhanced programming environment, and a new, well defined and examined user interface? This would be going the Mac OS X route. In this model, I am not advocating abandoning X completely, but instead for backwards compatability run a rootless X server.
1) Irix is not a microsoft product. Score 1 for SGI.
2) The truely high-end stuff tends to be done on unix type workstations. Perhaps this graphics card garbage is true in the home market, but not on the professional one.
3) If you're willing to pay for X (you're willing to pay for windows aren't you?) You can always buy implementations that support the latest hardware.
4) There are X-Servers/Clients with extremely advanced graphics features. Again, you generally have to fork up some cash, but you're willing to pay for windows, aren't you?
While I do appreciate the flexibility of X Windows, I honestly DON'T think the windowing system and toolkits should be these totally orthogonal projects, and the toolkits just "draw as they see fit" on a canvas that they expect the windowing system to render dumbly. This is the X model, inherited from the dumb terminal days. I have had this argument out several other times here on
I certainly believe firmly in the benefits of choice and competition, and agree with most
I appreciate what X Windows does for us, I just don't think it's the right solution for a desktop operating environment. Because of all the X apps out there, I think anything that comes out needs X compatibility as a backwards compatible route, but I don't feel that we should look to X Windows for the future. Just my opinion.
I think part of the problem is the fact that there never seems to have been any coherent work done on this. The windowing system oriented people who work on X say "the toolkit authors fault". The toolkit authors would say "it's your drivers or the limitations of X Windows"
Nope, read the thread I quoted and you'll see that gtk developer Owen Taylor agrees and that gtk 2.0 includes some of the optimization mentioned. The toolkit and X11 authors do work together on these things, and the toolkit authors have had a huge amount of input into the design of the XRender extension and the DRI infrastructure.
While I do appreciate the flexibility of X Windows, I honestly DON'T think the windowing system and toolkits should be these totally orthogonal projects, and the toolkits just "draw as they see fit" on a canvas that they expect the windowing system to render dumbly. This is the X model, inherited from the dumb terminal days.
Actually that's not the X model (BTW, X wouldn't run on a dumb terminal--even vi wouldn't run on a true dumb terminal (ie glass tty)). The X model is to provide high-level graphics primitives to the application, which then submits them to the server which can turn them into whichever low-level calls are most efficient on the hardware in question. Not only that, but the library used to submit those request can (and does) batch them together so that the application writer can have a simpler model and still get efficient code--for instance, multiple XDrawLine calls are batched by XLib into a single XDrawLines call that's sent on to the server, saving on round-trips and in some cases saving on bus traffic to the video card by eliminating redundant traffic. Or servicing those high-level requests in whatever manner is most efficient for the hardware in use.
Highly efficient graphics can be done this way. Witness SGI, who were for years the undisputed leaders in the graphics field. They used X11.
But think of X as being more of a device-driver with a unified API, the GUI is to be built on top of that. It's a highly reasonable and well considered model that is ideal for building the high-performance GUIS of the future on. Far better than e.g. a framebuffer, which is already obsolete (doesn't handle many 2D features like overlays & alpha blending, doesn't do 3D acceleration, doesn't allow for hardware security a la SGI, doesn't handle hardware video decoding, etc) and is low-level enough that you can't have the driver do intelligent optimizations without rewriting the apps. And designed with the foresight to be extremely flexible.
Sumner
rage, rage against the dying of the light
Now, about latency. If you compare local access to X11 with local access to, say, Windows or OSX, I don't think you'll see practically significant differences. (Well-written applications will use shared memory for any kind of bulk data transfer.)
About the graphics model. The X11 graphics model is complex. It really does expose a lot about the underlying graphics hardware to you and it gives you pixel accurate rendering. That was crucially important in the 1980's and has served X11 extremely well for nearly two decades. Today, it's less important, since you don't get a lot of low-depth screens anymore. I would expect that in the future, the RENDER extension will become the predominant graphics API and the core X11 graphics APIs will receive less attention. Implementing the core X11 graphics doesn't need to be a lot of code, and you don't have to worry about all the oddball bitmap formats if you don't want your applications to run with oddball display devices. But in some markets, that kind of control is important, and X11 provides it in a portable and network transparent manner.
Overall, X11 is an old system and has accumulated some cruft. It's also a complex system because it does some really nifty things that neither Windows nor MacOSX have really tackled well. On balance, I think it's still a very modern network transparent windowing system, and if you were to design something with similar functionality today, it wouldn't look all that different or be all that much simpler. So, I vote for keeping X11, not because it's widely used, but because it's actually quite good. And I hope people will spend the time to understand X11 better. The people who designed it were very good; give them the benefit of the doubt.
Those are problems with the toolkits. None of the modern toolkits (Gtk+, Qt, wxWindows, FLTK, Mozilla, etc.) use X11 very efficiently. The redraw logic in Gtk+, Qt, and Mozilla is, in fact, in violation of X11 guidelines. The reason is that these toolkits are mostly written with a Windows GDI mindset, either because that's what their authors are familiar with, or because they want to achieve cross-platform compatibility and it's easier to treat X11 as a second-class citizen.
applications all have inconsistent look and feel,
X11 is not a user interface or desktop, it's a network transparent windowing system. If your user interface is inconsistent, you only have yourself to blame for it: don't run X11 applications written for different toolkits or desktops. You get similar inconsistencies if you start running Motif or FLTK or wxWindows or Mozilla applications on Windows or MacOS.
And if you say that I need to tweek it to get it as fast as MS, then MS wins.
I'm posting this from Galeon running on a vanilla Debian installation on a 200MHz Pentium with 64M of RAM and a 5 year old graphics card. Windows wouldn't even boot on this configuration without excessive paging, and IE is a dog. In the past, all the graphics benchmarks I have done ran faster on good X11 implementations than on Windows. So, I challenge your implicit the claim that Linux+X11 is less efficient than Windows. But even if that were the case, on 1GHz machines with 512M of RAM, any such differences are academic.
However, the Gnome and KDE desktops are comparatively slow and resource intensive, probably similar to recent versions of Windows. I couldn't run them very well on this machine (although they do run). That is something you will have to take up with the authors of those desktops. But they, too, are designed for modern machines, where it really doesn't matter.
XFree86 lacks support for the hardware command buffering features found on nearly ALL modern graphics cards. These buffers can be very deep ( roughly 1 million entries). This allows you to batch up all your drawing operations in memory and tell the card to read and execute them without host CPU intervention. In the time you are waiting for the card to finish, you can call something like usleep, etc. to wait for completion. Many of the XFree86 drivers I've looked at do not do this. The driver just has a while() loop (or equivalent) to wait until the card has finished drawing. This sucks up CPU cycles and eliminates any possibility of concurrency.
With XFree, it's like having a dual CPU system when only one CPU can work at a time.
On the S3 Savage chips there's no need for DMA to do this, the hardware will buffer it in Video RAM. So it should not need a kernel module. I still don't understand why they haven't enabled it in the XFree86 driver. Once it's enabled, all you do is just write the commands to the BCI area (in register space, 128KB long) and the card will handle the FIFO in video RAM automatically.
I like a lot of things aobut Plan9, and eight-and-a-half (the windowing system). However I do want to point out one disadvantage of how they handle mouse events. If all you care about is "has the mouse moved into/out of this box" you still have to use a ton of bandwidth to track the mouse. In X11 if you make that box a sub-window you can ask for enter/leave events and not consume 56+Kbits watching the user twiddle the mouse around.
Other then that eight-and-a-half rules. I really like that the same devices it offers to client apps are the ones that appear on the bare machine so (a) you can run a window app full screen without the other stuff, and (b) you can run eight-and-a-half inside eight-and-a-half without doing anything special like you need to with XonX or the like.
Plus Plan9 is cool, so I am compelled to like everything about it :-)