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.
Getting the specs from ATI (without an NDA that would prohibit an open-source driver) is probably the hard part.
Disclamer: I'm not a fan of MS, I'm a fan of whatever works the best for the job.
There are VERY obvious performance differences between any version of Windows and as new of version of X as you want. X Windows programs flicker like mad when moving or resizing, objects aren't responsive, the mouse frame rate is low, applications all have inconsistent look and feel, keyboard support is lacking... And if you say that I need to tweek it to get it as fast as MS, then MS wins.
I really want Linux and BSD's to thrive, but if they really want to become desktop operating systems, they need some fundamental changes to the GUI.
Here's what I suggest:
- Build new server built around a sort of COM (like ActiveX). If the COM objects are installed on the server instead of client, there will be less traffic going through pipes (less latency) and makes the GUI more object oriented at the root (remember NeXT?).
- Separate Server and graphics drivers. Why the frick is ATI Raedon changes in the X11 change log? They should be driver changes, not server changes.
- Design the GUI interfaces without a mouse. Everything should be accessible through a keyboard, no exceptions.
- And speaking of NeXT, they had some great ideas on how to take advantage of 8 of the 32-bits of color.
May the flames begin.
Ozwald
Berlin will be good if its compatible with X but the problem with berlin is its so new that its dangerous.
I think something more like directFB will be fine, however if berlin development gets some kinda boost, well ill switch to berlin as long as it runs all my programs.
If you use Linux, please help development of Autopac
I'm curious, anyone have any experience with the other x86-based X systems? I know there are a couple of non-free ones, but I've never had the chance to see any of them. How do they measure up?
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?
X sucks at rendering compared to its competition.
OSX totally destroys it, even WindowsXP,
The Xrender extention is nice, but its going to take years like you said, just to get stuff like alpha channeling.
I agree X should use Xrender extentions however what are people to do in the meantime while OSX and XP kick our asses in the eye candy department and everyone says "Linux on the Desktop is dead" Before it even gets a chance to come out of the gates?
Whats wrong with having a directfb or berlin alternative which unlike Xrender, do the stuff you talk about RIGHT NOW.
I honestly dont think the media will sit and wait for 2 years or more while you slowly code Xrender.
So the option is, wait a few more years for Xrender to be completed, or check out stuff like directfb and berlin which claim to do what Xrender will do years from now.
Whats the best option? People want alpha channeling, scaling and OSX like effects, alternatives claim to be able to do it now, they port GTK and QT, and they claim to be compatible with X.
I think this should be discusssed more.
If you use Linux, please help development of Autopac
Thanks, finally someone who understands compared to others assume suggesting COM is a trick to sneak MS technology into Linux.
I'm not for destroying extensibility. Instead, I would love to see a system where objects are installed onto the server, maybe even at run-time off the web if an application needs it. Even better, a system where a developer can extend an existing control to add new functionality or build a new control off of generic objects.
Just a suggestion, if you guys don't like my ideas, I won't lose any sleep. Just trying to help.
Oh, and the driver thing too, don't forget that.
Ozwald
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.
Interesting.
Do you know how it will handle different resolutions per monitor on laptops?
On my thinkpad I can have a max. resolution of 1024x768, whereas on my external CRT monitor it's 1600x1200.
In order for me to get 1600x1200 res. on my crt monitor on my laptop was to add a special directive in the XF86Config file (usecrt or something), but that meant that I had to change the XF86Config file everytime I switched to and from my LCD and CRT.
Windows however does this automatically.
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 :-)