Slashdot Mirror
DRI Comes to DirectFB
Pivot writes "To further heat up the discussion about the future of the graphical desktop on open source OSes: Now the DirectFB project works with DRI!. Screenshots are available. I guess what is lacking now is only XAA driver support, or native drivers for your favourite graphic card." We've mentioned DirectFB before.
It sounds like a great project but native driver support and linux, whoa back right up. For most consumer hardware that is far form a reality. Personally I have an ATI card so this is good for me but it may take quite a while to ad support for others. I can't wait to give it a try though should be exciting to see and work with because gui speed definently is lacking in the major desktops for linux which just slows down the programs that run on them.
Checking out my form of escapism.
"The embedded-1-branch of Mesa is a port of DRI to the framebuffer device (fullscreen only, no input). Currently supported are ATI and Matrox (after porting the driver a few days ago)".
Once again NVIDIA is not supported. NVIDIA wake up and release your specs and manuals under NDA to the developers. You are only hurting yourself by denying your product less acceptance in the open source world. And for the NVIDIA supports open source argument try moving between X versions and see how well your NVIDIA card is supported with all the bells and whistles you thought you paid for.
Anyone know where I can find a MATROX AGP 1x card?
A disgruntled NVIDIA customer.
I use X, running apps off of a central development server. ddd over the network anyone? Every Windows box here even has an X server installed. I use X at home, and often run apps from home when at work using you gessed it, the X protocol.
I need X.
As for Linux not being a "real gaming platform", hardware accelerated OpenGL is fast enough on linux. And if you actually can get the specs to your graphics hardware, as in the PS2 linux kit,
there's nothing stopping you from writing "real games". SDL give you everything you need, running on XFree86, framebuffer, etc.
PS I write games for a living.
Dave
If the net result of a native fb GTK lib is that someone can run all their apps locally with better performance and less screwing around in different places configuring mice, resolution etc., and better support for their hardware and better support for games and multimedia, it means Linux is better suited for the desktop. It doesn't preclude using X11, or even running X11 in rootless mode (as it does on OS X) if people want to but it sounds like a great project to support.
And in some ways it helps Xfree86 since a single direct DRI driver can support a whole range of display hardware without XFree86 having to maintain them themselves.
That's one of the stupidest things I've ever heard. It's a retrograde step. The reason that X has been around for so long is because it's a design that works. Hell, even NT, 2K and XP have client server graphics at the core, just not as good as X.
The problem with Linux is not the X design but the implementation. XFree is rather boaty and slow. What we need is a new version of X rather than to throw away the protocol. There are plenty of established extensions to support graphics, overlays and the like when you need them.
You must also remember that Linux != UNIX. X wouldn't die even if the kiddies stopped using it on their Lienucks boxes. I have Solaris and IRIX machines at home which use X. Your NVidia graphics card was probably designed with the help of engineers who developed IRIX's X implementation.
If someone wants to do a framebuffer implementation than fine. The whole point of open source is that it allows choice. If someone wants something and they are willing to develop it for the community, that's great. Open source also exhibits evolution, survival of the fittest. Those which are are found wanting fall by the wayside.
X is still here because it works, plain and simple. Throwing it away would be madness.
Face it: we don't need X any longer.
Then why is it that Microsoft keeps trying to copy it (failing miserable) ala Remote Desktop etc.? I for one would love a handheld device that gave me complete control over my home machine from anywhere it the world. You can't do that without a network GUI.
X is bloated and you compare it to "High Performance" Win XP? From what I have seen XP is useless on machines less than Athlon or PIII, and even then it starts slowing down if you have more than a few apps open, while my wife can run Mandrake 9 with full blown KDE, Mozilla and Open Office (even at the same time) on a K6-2 450 with only 192 megs of RAM. Its not the snappest machine in the world but its useable enough that I don't get annoyed at it. Its even faster when I run Blackbox.
KDE works automatically. And this would weed out Gnome this obsolete, second desktop system which just draws resources from the KDE pool and thus slows down advancement of open source systems.
If you want your apps and look and feel dictated to you then go back to Windows because that's what its for. No choice, you can feel good that everybody just uses what is handed to them. Linux is about choice. While I agree that Gnome and KDE could work better together (and should strive for that goal) I would be extremely upset if the people that work on Blackbox, or GAIM or Mozilla decided they were going to work on KDE apps instead. I like the GNOME apps I use, I like Mozilla and no one has the right to dictate those choices to me.
Open Source development isn't about what everyone wants, its about what the developer wants and she/he's nice enough to give that to other people in case its useful to them and they are free to do with it what they want.
Finally are you a KDE developer? because if not then you certainly don't have any right to complain about other people not working on the project you want them to work on.
The Anti-Blog
I've noticed that a lot of the discussion on DirectFB is like all other X 'replacements' -- half the people talk about how great it will be because it will jettison the useless bloat in what they call outdated technology, while the other half rail about the loss of the network-transparency that they can't live without.
Well, this may seem naive, but maybe both sides are right? I mean, sure, network-transparency is wonderful but how many people are really using it? 1 in 20? Maybe? At the same time though, that one person is probably using it for somthing uber-useful, like eliminating 200 desktops in lieu of dummy terminals :)
So here's the stupid question: why didn't (or hasn't) someone build a graphical syb-system that's modular? Why can't you have a well-written, clean API (I've heard horror stories from people who've had to write code directly to X) that lets you plugin in modules like 'network-transparency' or 'anti-alisased fonts', or even everyone's favourite 'alpha-blended windows'?
I'm not saying this would be trivial, but surely it'd be worth the time and effort so that the 95% of users who don't want it can simply turn off network-transparency, and the 5% who do can plug it in without a lot of hassle.
As I said, surely this is naive. So flame away.
Wood Shavings!
- Godai
Your answer is exactly the attitude of the X people/defenders I wanted to critizize. Basically the attidude X does everything right there are always others to blame.
:-)
:-)
But lets go back to the arguments. Your speed argument is exactly what I wanted to point out
(X is not slow I compared X to X), face it no matter what window manager, put an X box side to side to a MacOSX Jaguar box or WinXP box and you will see that both later ones outperform your fabolous X box by the factor two til three. That KDE is another drag on the whole performance is another issue. As for your network argument, you picked up pretty much the only app which you can tunnel via a modem connection, the fact that an entire RDP Desktop needs as much bandwidh as xterm alone should say a lot.
As for your compatiblity argument. 99.9% of the most important apps sit on top of toolkits, now if qt and gtk2 are ported (gtk already is) see people flock away from X left and right.
Again Xterm probably besides some other stone old apps will be one of the apps which won't be portable.
XV, nice argument, but you know were the DirectFB project developed from, there won't be too much need of XV then
As for bloat. 7 millikn lines of code for a simple windowing system is bloat (as for m%$ windows it has around 10 million lines but only a fraction of that goes into GDI and other directly windowing related stuff) and basically unmaintainable, constant reports of bugfixes never worked in
in various forums pretty much resemble what I assume.
Just another question, now that you have given valid arguments, why do 99% of all X apps implement things wrong
"Your answer is exactly the attitude of the X people/defenders I wanted to critizize."
I don't know if you are the same AC as the one I'm replying to, but this sentence imply you are.
"Basically the attidude X does everything right there are always others to blame."
X doesn't do everything right. But there are other things to blame.
And I critisize people like you because of your attitude: the attitude that all bad things in the world is because of X and that it must die off no matter what.
"But lets go back to the arguments. Your speed argument is exactly what I wanted to point out
(X is not slow I compared X to X)"
OK if absolute numbers from x11perf aren't enough I'll show you my results from a Windows ME - XFree86 comparison.
A year ago I wrote an app in SDL that blits 1000 640x480 surfaces and calculates the average frames per second.
On Linux, I compiled it with no optimizations (gcc 2.96). The SDL binaries are from RedHat: optimized for i386.
On Windows, I compiled SDL manually using Mingw (gcc 2.95) with Pentium optimization, and the testing app (no code modified) with no optimizations.
Then I ran the test app in both Linux and Windows. I expected the Linux version so show a slightly lower FPS because of the IPC/driver/whatever overhead. But surprisingly, the FPS in Linux is VERY close to FPS in Windows. The FPS in Windows is like 2 frames higher than the FPS in Linux. I repeated the test several times and sometimes the Linux FPS is slightly higher, sometimes equal and sometimes slightly lower.
Conclusion: on my system, XFree86 is just as fast as Windows ME in blitting. The differences are caused by other processes and other random stuff.
"face it no matter what window manager, put an X box side to side to a MacOSX Jaguar box or WinXP box and you will see that both later ones outperform your fabolous X box by the factor two til three."
Not on my machine. See above.
"the fact that an entire RDP Desktop needs as much bandwidh as xterm alone should say a lot."
I've never used RDP before so I'm not going to comment on this.
"As for your compatiblity argument. 99.9% of the most important apps sit on top of toolkits, now if qt and gtk2 are ported (gtk already is) see people flock away from X left and right."
Right, just take a look at the Nautilus/kde-libs/gnome-panel source code. You can find lots of references to xlib functions.
"As for bloat. 7 millikn lines of code for a simple windowing system is bloat (as for m%$ windows it has around 10 million lines but only a fraction of that goes into GDI and other directly windowing related stuff)"
How do you know how many lines code the GDI has? (*insert scary music here*)
Windows by default doesn't ship all drivers for all video cards. XFree86 on the other hand ships *all* drivers it has. I think it would be more fair to compare XFree86 minus drivers with Windows GDI minus drivers.
"and basically unmaintainable, constant reports of bugfixes never worked in in various forums pretty much resemble what I assume."
I think that has more to do with their organization than X's architecture. And that's exactly what Keith Packard is protesting against.
If there's something better than X, in all areas, then by all means go ahead and replace X. But there is no such thing. DirectFB is not a worthy full replacement for X and is not finished yet. Fresco is far from usable. GGI is stalled. What else is left?
Until somebody comes up with something significantly better, we should fix existing thins rather than complaining over and over that X is the root of all evil and that it must die.
This is a possible reason why Microsoft Windows 98(tm) running on a 100mhz Pentium seems so much snappier for minor UI-interaction tasks (pulling down a menu) than a same-vintage Gnome on identical hardware.
I'm running KDE on a P4 1.4Ghz machine. My boss runs Win2k on a P4 1.5Ghz machine. I'm assuming that KDE performance is roughly comparable to Gnome performance.
Anyway, my boss comes by and asks for some information. I bring it up by opening a Konqueror file manager window to an NFS mount, then opening the file in OpenOffice. He thanked me, then remarked how much snappier my desktop was than his. Huh? That was NFS plus OpenOffice, in case you didn't notice. Everyone on Slashdot tells me that X/KDE is slower than M$/Windows. They tell me so often that I was starting to believe it.
So I started paying more attention to the speed issue between KDE and Win2k. I've come to two conclusions. One is that the X11 process doesn't have a high priority by default. The other is that KDE doesn't have application resources (icons) embedded into the executable. I only notice "sluggishness" when I'm doing CPU or filesystem intensive stuff in the background, like a compile. Funny thing, I notice an even worse sluggishness under the same conditions in Win2k.
I've also noticed that Win2k doesn't do nearly a half the things that KDE does. In terms of just the graphics, all Windows does is draw some primitives on the screen. For a draw versus draw comparison, Win2k is going to beat X11/Qt every day of the week. But for real work, KDE beats Win2k hands down. I click on an mp3 file in Konqueror and kaboodle opens up almost immediately. The same thing under Win2k takes about three to five seconds for an embedded MediaPlayer to appear in the explorer sidebar. Running fifty different applications under KDE imposes no performance hit. But the same under Win2k makes a significant hit. Copying five thousand files from one directory to another (on the same partition) is almost instantaneous under KDE. Under Windows this can be almost painful to watch. This is really the filesystem (UFS2+S versus NTFS), but the user isn't going to care.
Why do people think that Windows is faster than KDE/Gnome? Because they've been told so hundreds of times. For minor UI interactions, they're right. But for the complete GUI as a whole, they're wrong.
A Government Is a Body of People, Usually Notably Ungoverned
Hmm, let's do a little survey:
BeOS --- Known for being blazingly fast, if anything. It was pretty much a microkernel for god's sake. Used IPC for everything, including sending data to the app_server (the equivilent of X in its architecture).
Windows --- All the NT kernel-based OSs use an IPC mechanism called LPC to communicate with the Win32 server and the GDI.
OS X --- Not known for having a fast GUI, but the fact that it runs the GUI in a server (lightweight window process in OSX-speak) isn't the reason.
The big thing is that IPC isn't that much of a performance hit. Graphics are easily batchable, so sending a whole bunch of drawing commands doesn't hurt anything. And you know what? You're going to be batching them anyway, since sending individual commands to the graphics card over the AGP bus is not exactly the way to get optimal performance. Now, there *are* some defficiencies in all existing architectures. The ideal method, for current hardware, is what is used by OpenGL ICD's on Linux and Windows. The actual graphics library is a hardware-specific module dynamically loaded into each application. The application calls the library to do drawing commands, and the library creates a hardware-digestible command buffer right in memory. Periodically, this buffer is DMA'ed to the hardware. Now in all current systems, there is an extra step --- the graphics server is the one that creates the command buffer, so you have one extra step converting a high-level window system command buffer to a low-level graphic's driver command buffer. To tell the truth, for 2D work, this really doesn't matter much. The *core* X protocol (no shared memory or anything) is fast enough on my machine to do x11perf -putimage500 at 80fps. That means copying about 80MB of images to the screen every second. Let's just say that no desktop application has graphics complex enough to need this kind of bandwidth. The bottleneck is clearly somewhere else.
A deep unwavering belief is a sure sign you're missing something...