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.
In this day and age, whoring Karma on Slashdot is easier than ever. With more moderators and a lower signal to noise ratio (If you don't know what that means, don't worry!) means that Karma can easily be gained by following a few simple rules when you are carefully crafting your Slashdot post.
- Vaguely mention the DMCA. It doesn't matter what the topic of discussion is, those four magic letters glow like a beacon to any moderator with points.
- You can get double points if you spell the acronym as DCMA throughout your post. This is especially effective if you're replying to someone who has just used the correct acronym in their post.
- MPAA and RIAA are another pair of gems. Use the phrase "RIAA/MPAA" in every post you make, and that Karma will flow!
- Always confuse the two. Complain loudly about the MPAA suing over MP3 downloads, or the RIAA trying to stop you from downloading DeCSS.
- Don't bother to understand the difference between Patents, Copyrights and Trademarks. If the topic of discussion is about patents, claim that "this wouldn't have happened before the DCMA" (See above)
- Always remember, It's Microsofts Fault! Try to craft vague conspiracy theories that include Microsoft.
- Spell it "Micro$oft" or "M$". Moderators will lap it up.
- If all else fails, blame the Government. Do not at any cost attempt to understand basic politics, as that will make you look opinionated. Just blame the current political leaders.
- Likewise, blame the French. Double points if you use the phrase "Cheese eating surrender monkeys".
- If you're losing the argument, start a flamewar about the war with Iraq. Accuse the other party of being French, or "a pinko commie"(See above).
- Claim that you only download stuff using P2P to "try before you buy".
- Start a flamewar by claiming that "Piracy isn't theft". Violently flame anybody who dares to disagree with you.
- Double points if you attempt to defend your position by stating that you "wouldn't have paid for it anyway, so they haven't lost a sale".
- The Iraqi Information Minister was funny, wasn't he? Your post should be like one of his speeches. It'll be funny.
- Ensure your sig has a Karma joke in it. You know the ones, something like "Karma: Bogus!" Ensure you retype your sig every time you post a comment; double sigs look cool and you wouldn't want the people who have sigs disabled to miss out, would you?
- Remember! Never, ever read the related article or any background information before you state your opinions. You're too busy to do that, and its not like the moderators will notice either!
Good luck! Within no time at all, your Karma will be Excellent!1) Today, DirectFB can do some things XFree cannot, but the reverse is also true. But, the XFree infrastructure could be (and will be) upgraded to do stuff like full use of hardware accelerations, proper save unders, alpha blended windows and so on. DirectFB cannot gain network transparency or code portability however.
2) On the other hand, using DirectFB does not mean we lose network transparency. The X11 protocol won't disappear. If it had better hardware support, or was able to use the XFree drivers, I'd have no problem at all using this software. For apps that used GTK/Qt I'd always have the choice of network transparency when I needed it. Software written for DirectFB specifically probably isn't the sort of thing you'd want to run remotely anyway.
3) Window transparency is overrated. Window double buffering is not.
4) DirectFB still has a lot of questions to answer. AFAIK there is still not window management protocol for instance - X11 provides a lot of things most people don't think about, DirectFB would have to provide equivalents first.
5) Half the comments in this thread about XFree will be misinformed ;)
I read that as "DRI Comes to DirectFBI", and just couldn't understand what DirectFBI is... DirectSound, DirectX, DirectFeds?!
The idea is to replace X with something closer to the hardware as far as I know, but today it's mainly useful in embedded scenarios. They have a backwards compatability thing for X clients, which means if you have a supported card you can run your desktop on it and make windows transparent with the capslock key. It's fun for about 2 minutes I should imagine.
As an aside, does anybody know if the girl in that screenshot lives is single? :D
"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.
It's tailored for gentoo, but most stuff applies to most distributions I guess. Not that I'm using them. ;)
o r
http://forums.gentoo.org/viewtopic.php?t=49036
Then you can get consoles which look like this:
http://www.alledora.co.uk/images/fb0.jpg
http://www.bootsplash.org/silent-mode.jpg
Files can be recived from
http://www.bootsplash.org/
I'm too stupid to preview.
Skate or die, dude!
Screenshots are available.
~ s/are/were/
Karma: The shiznight, mostly because I am the Drizzle.
That almost made sense until you started ranting about Gnome being obsolete.
I don't use KDE or Gnome, but I do think that the choice is a good thing.
Eh? With the KDrive Tiny X server memory use is negligent... maybe next you will say that terminals should stop being ansi compatible, as no-one needs that too? It really doesn't add too much in the way of resources if thats what your looking to do and you do gain a lot
Embedded devices are probably _the_ place where DirectFB makes the most sense. These don't have the same needs a desktop has, and lack the network interfaces (right now, I guess) to make the networking features of X useful.
However... I don't see any point in moving DirectFB to the desktop, or using it anywhere that has a network interface and the appropriate hardware to run X. There are many, many areas where X makes a lot of sense (even in embedded devices!), and DirectFB is not going to be performance panacea that some people make it out to be. It's going to be best as a "light" display system for embedded hardware, IMHO.
-Erwos
Plausible conjecture should not be misrepresented as proof positive.
Yeah, I've got a machine enough power to make a 70s era mainframe look as powerful as an NES. I also have a fiancee who lives with me. So, should I build yet *another* monster machine for milady to use? Or should I get a couple of refurb laptops, slap Debian on 'em, and use them for remote X sessions and make efficient use of my uber-powerful Athlon with a gig o' RAM?
After all, I can get a couple of secondhand Dell laptops for the price of another Athlon with all the trimmings and an LCD. I think I'll stick with X. If it isn't network transparent, it's crap.
speak for yourself. X is just fine for my needs and I can even play UT2003 on Linux and ALMOST get (3 or 4 difference) the same frame rates as I do in XP. If you don't need network transparency, fine, but it does NOT MAKE YOUR DESKTOP GO ANY SLOWER!
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 you would port Qt to DirectFB... what would manage your windows? How could DCOP work without authentication over X11? What server manages drag&drop and cut&paste?
X11 does far more important stuff than only letting you access the framebuffer.
Beside that, no mainstream system will have a chance to succeed if it only fulfills the needs of 95% of the users. Unless you get 100% it doesnt have a chance. MS understands this, thats why they have put *a*lot* of effort into the Terminal Services and RDP.
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.
Maybe now you realize why closed source drivers are worse.
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.
Dirty Rotten Imbiciles are going to work on a free and open project...glad to see punk music making the "crossover" with computers.... ...oh wait
So rise up, all ye lost ones, as one, we'll claw the clouds.
You see, this is not a new nor innvoative technique! M$ also has some graphics in kernel - this is what allows them to pander to the MPAA/RIAA when they demand unbreakable DRM. They is almost certainly patented as a result! Do you want to be sued for playing MP3s with DeCSS on Linux? NO! There is only one choice - just say no to having your multimedia use the kernel... just say no to DRM!
DirectFB puts our freedoms at risk my fellow Americans, because the government assumes that all P2P users are terrorists, as opposed to freedom loving consumerists who merely wish to try before they buy. Everybody knows that piracy isn't theft - how could it be, when most pirates wouldn't have even bought a copy anyway?
So you see, if people use DirectFB you don't only lose network transparency (who uses that anyway?) - you lose something far more important - your FREEDOM. With X, at least you can swap out XFree for another server, becuase being BSD licensed means it is truly Free, unlike that pinko commie Linux kernel.
Karma: Was Excellent, Before I Posted This
Karma: Was Excellent, Before I Posted This
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
All good questions. I'm not knowledgeable about the internal workings of Qt/Embedded, but I know my Sharp Zaurus runs a version of Qt without running X at all.
But, in case you didnt notice, you always see one app at a time and everything runs as root.
Cos anyone with any real experience uses remote displays regularly.
We use it for engineers, for secretaries, for managers, for salesmen, for janitors even, but it seems that script kiddies like you don't use it.
BTW, You wanna know why xterminals are still used and why the X protocol is more important today than it's ever been before? Nothing to do with hardware costs these days. It's because 1 administrator can manage hundreds or thousands of desktops, with ease. Wanna know what the single largest set of costs in I.T. are? Support. Those dozens of wintel administrators needed to manage the big iron mainframes under every desk.
Face it, you're a moron.
Government of the people, by corporate executives, for corporate profits.
Some people need X11 and some don't. If local desktop performance and modern windowing behaviour can be achieved by completely bypassing XFree86 and its associated window manager and other processes then it should be done.
I was wondering the same reason. Why cant DirectFB be the driver/interface for the Display, and let Xfree just port the Xserver to the OS. Xfree doesnt need Driver support anymore, All drivers are for DirectFB now.
Xfree for cygwin doesnt care what GFX card I use, and I can use it in rootless mode. Only thing I wonder is if Xfree can support all the hardware features in DirectFB. (And widget support doesnt rely on the gfx card, just the xserver, so no problem with X network transperancy)
Sounds like a great Idea to me, let xfree be a straight xserver, and let DirectFB handle the gfx drivers. (Then we dont have to wait for Xfree to put the driver fixes that has been shelved for months, example ATI's submissions, and the reason for the Xfree spinoff.)
Dirty Rotten Imbeciles, a great early punk/thrash crossover band.
Let's fork XFree, merge it magically with DireectFB and produce a lightweight X-windows brother...
:)
Then, let us call it DirectX.
I have to second this notion. I've always looked at Unix/Linux as the ultimate pick-and-choose OS .. I can build in what functionaility I need and get rid of functionaility that I don't need. Unlike Windows where lots of apps are bundled (IE, Outlook Express, etc..etc..), Linux gives me the freedom to customize virtually every aspect of my system...
well except one --> X11.. It might be great for a network / sysadmin configuration, but for a desktop, it blows. With so much activity happening at the desktop, it is imperitive that X11 be REMOVED!
We need to back something like DirectFB that will allow for a much more responsive interface, an interface that can meet the needs of desktop users and provide for the needs of the desktop Linux user. Like Apple, if X11 is needed, it should be provided in-addition-to the core fast desktop.
It would be pretty cool... :) Not quite sure of the likelihood or feesibility of such an undertaking, but definitely something to think about.
Wow, another DRI reunion tour? Any original members on board this time?
wordclock records
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
Heck, even if it IS a KDE developer, then he STILL doesn't have any right to complain about other people not working on the project he wants them to work on.
I'm sorry, how does remote desktop fail to do the things we really want from X? Admittedly it does not allow you to run single applications on your existing desktop, but what we really want it for is for logging into systems remotely and doing maintenance. It also does things which X doesn't do without addons, such as audio redirection. (I know you can use network audio daemons but now you have another network connection to make. It's fairly trivial to add it if you're already using ssh tunneling but otherwise it can be a network annoyance.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Rather worryingly, it's at -1 Funny and yet no "Overrated" mods are shown in the box below - considering that overrated moderations are no longer shown and are not meta-moderated, this seems like a wide open hole for people who want to abuse the moderation system. What is the reason for this inconsistancy? Why is overrated/underrated special?
1. Loadable modules are nice. The seem to keep complaining if the driver version differs from the kernel version.
2. If I want to write a third party GPLed driver for windows, then I can. Most people don't need to and so they don't bother.
3. I suggest proper coffee. Make sure it's freshly ground.
Troll mode off, if I did decide to write a kernel, I'd probably write something very different from Linux. Aspects of it are quite good, especially the support for obscure filesystems, but really adding drivers is rather unpleasant. Somehow BeOS makes life seem so much easier. Just drag and drop. Things just work.
Havin streamed an entire desktop with less bandwidh than a single modern x app with a compressed protocol is something I would hardly call a failure :-)
...you know, a 21st Century version of the GUI by (Intergalactic) Digital Research, Inc. (DRI)... you know, the originators of DOS, when it was known as *cough* *cough* C/PM... I'll go find my Atari ST for comfort...
"Right now, somewhere in this world, Scott Baio is plowing a woman he doesn't love," - Peter Griffin, *Family Guy*
Other people have said it, but you are so wrong I have to say it again. Remote Desktop and Terminal Services are not failures. They're the only way we can serve database-intensive applications to remote sites on slow connections.
Microsoft has got some things right. Deal with it.
irb(main):001:0>
If you are looking for native driver support for ATI in a laptop, you may be out of luck since ATI does not support these cards. They claim it is up to the OEM e.g. Dell to provide drivers.
More stuff to hook into DRI! But wait...has anyone at all been working on actually STABILIZING DRI?!
DRI is a mess. What's the most stable card...the ancient Mach64? I can't recall DRI for the G400 ever working reliably. It would consistantly lock up my Voodoo3 based machine as well.
DRI is why I went with NVIDIA. Say what you want about the closed drivers but hell, they work and they work WELL, which is more than I can say for ANY DRI drivers.
To prevent uninformed comments about X:
X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER
X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER
X WINDOWS DOES NOT USE NETWORKING FOR THE LOCAL SERVER
Look here for an explanation of what Unix domain sockets are. They have nothing to do with networking and are the most efficient form of IPC on Linux. As a bonus, you can write code which uses either AF_UNIX sockets or AF_INET (TCP/IP) sockets seamlessly--but AF_UNIX sockets still have nothing to do with networking. Got it?
"Crowd: X is bloated
i endly-Windows-XP has millions of code too.
o u-no-matter-how-uninformed-we-are"-zealot.
X DefenderS: X is not bloated it is just everything else on top of X"
Proof: use twm/fvwm/IceWM/BlackBox/Xfce. Behold the speed.
GNOME and KDE are slow, X is not.
"Crowd: Network Transparency is a hog
X Defenders:No it isn't there is just not a single app which does it right,"
Proof: try running xterm remotely. Now, do the same thing with Konsole and Gnome-terminal (2.x). Behold the difference in speed.
It is also important to know that XFree86 does not use TCP/IP locally! Pixmaps are transferred using shared memory. Other (significantly smaller) data are transferred using a Unix Domain Socket, which is just as fast as shared memory (at least on Linux).
"Crowd: X is slow
X Defenders: No it isn't run two X servers side by side and see that they have comparable speed"
I've never heard of an X defender say such a stupid thing. Obviously you made this up. That makes you a liar.
Anyway, it can be proven that X is not slow. Run the x11perf benchmarking utility:
x11perf -rect500
x11perf -repeat 3 -shmput500
On my system (ATI Rage 128, Athlon 1,4 Ghz), XFree86 can:
- Draw 1190 500x500 rectangles per second (1190 fps).
- Blit 210 500x500 square images per second (210 fps).
- Scroll 530 500x500 pixels per second (530 fps).
There, I have numbers. Now show me your numbers that X is slow.
However, if x11perf *does* report significantly lower framerates on your machine, then that only proofs that the main bottleneck is drivers, not X itself.
Crowd: X is bloatware
X Defenders: No every single line of the 7 million lines of code is needed, even the code from the flight sim"
Lots of code does not equal bloat. I'm sure you already know that, but you only say this to troll.
The oh-so-high-performance-and-oh-so-consitent-and-fr
"Crowd: Look there is something better and faster
X Defenders: We don't need that we have network transparency (which implicietly is unusable over slower lines)"
Except DirectFB is not better and faster. Hello, there's more about a windowing system than just drawing pictures!
- Even with this OpenGL/DRI backend, DirectFB still doesn't support nearly as many video cards as XFree86.
- What about inter-process communication? Like drag & drop or event notification?
- Where's the compatibility? You can't expect everybody to rewrite their app for DirectFB. Oh sure there's XDirectFB, but 1) doesn't that make the whole point of ditching X a joke and put us right where we started? 2) does it support important extensions like Xrender, Xshm and XVideo?
You are just another "we-are-the-biggest-group-so-we-are-better-than-y
This will never replace X11 because it has support only for Linux. What about all the other unices out there?
Great Looking Website Templates
%s/a great/the great/g
/.
Cool that DRI is getting some good plugs on
(+1 Funny) only if I laugh out loud.
Can I ask you a question? What exactly does this have to do with DRI and DirectFB?
;)
Aww hell, I'm anonymous, so I'll answer.
1. Compile your kernel without module versioning.
2. Good luck getting it signed. However, that's up to you. Most people don't understand what a driver does, much less why one would need to be written.
3. I must agree.
I hope this answers your questions for today. Thank you for calling
Think hard. Imagine how network transparency would be "added on" to an API that is designed to not be network transparent, for instance one that uses shared memory to read/write to the screen pixels.
Answer: it is not possible. Network transparency requires design considerations in the API. Fortunately these requirements are exactly the same as are needed for all security and stability reasons so that crashing programs or hostile programs cannot take down the window system.
X already bypasses network code when the system is local. This is the only way to make "network transparency" a "plugin", and it is already being done.
Why is X slow? It is because of the horrid design of the Xlib api so that lots of graphics are impossible without huge amounts of communication, and because of huge numbers of synchronous value-returning calls (a mistake done, interestingly enough, because the designers were using local servers with low latency, thinking about the network would have prevented this), and because of the seperate window manager that makes synchronous update impossible no matter how fast your hardware or communication is.
The more important question is why are so many people with so little actual knowledge, all calling for the same things? And even better if they all get what they ask for, and it doesn't solve their percieved problem, then what boogeyman do they blame next, thereby sending the community on another fools errand?
Big hint to everyone.
1-First make certain you actually have a problem. Lack of knowledge can be a handicap at this point.
2-Second make certain that you have a full understanding of the problem. Lack of knowledge can be a handicap at this point.
3-Profit!! No now you can actually solve the problem safe in the knowledge that you identified the correct one, and know exactly what's good and what's broken.
How about Mauritias?
I know it and you know it, but it won't stop the morons who think that X uses networking every-fucking-where, including the local host. Schmucks.
And supporting open source served them well!
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
Can I ask you a question? What exactly does this have to do with DRI and DirectFB?
That's two questions. The answer to the first is "Yes", and the answer to the second is a complaint that drivers are rather difficult to install in Linux compared with just about any non MS OS. Said complaint was quite rightly modded down as a troll.
1. Compile your kernel without module versioning.
Can I do that? Fair enough. I'll look into it.
2. Good luck getting it signed. However, that's up to you. Most people don't understand what a driver does, much less why one would need to be written.
It's not essential to get it signed. Even XP will still use unsigned drivers, and unless MS want to annoy a lot of developers by forcing them to use a special "development" version of windows. Generally speaking nobody needs to do write drivers.
Really? The Linux kernel (the Linus tree, in particular) contains lots of driver code for hardware I'm sure Linus doesn't personally own. A lot of risky changes are meant for architectures that Linus doesn't have, or may not even have seen. In fact, it may be interesting to see what percentage of Linux (in terms of lines of code or whatever) Linus personally uses.
Yet Linus accommodates these changes, and adds them to his tree. They make Linux a better product for many other people, even though it does less than nothing (any feature you don't need is an unnecessary potential bug) for him. Do you think Linux would be nearly as successful if Linus refused patches for any hardware he didn't own?
Sure, the developer can do whatever he or she wants, but the successful projects keep their users in mind.
The parent to your article was IMHO a flamebait, as judged by the phrase "high-performance Windows XP". I don't think any serious /. reader thinks Windows any version is more "high-performance" than some version or clone of Unix. Prove me wrong!
YHBT. YHL. HAND.
-uso.
High performance?
C:\>_
Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
Look at that big white stain on her trousers.
Some guy musta walked by and...boing...wank...zoom!
X has been doing this since it's inception. Infact X was made specifically BECAUSE of this reason.
You obviously haven't compared X to Microsoft's offerings or'd you know just like anyone else. X has got it right in this arena. Also a 20+ yr lead.
"Somehow BeOS makes life seem so much easier. Just drag and drop. Things just work."
Why is it, every time I hear this? I expect the speaker to believe in magic?
There's nothing mysterious about what's happening. Someone else has done all the work for you.
If Linux, like Windows came with the drivers on a CD, would that be mysterious? Would it "somehow (shrug) just work"?
Big Hint:
1-A lot of manufacturers aren't supporting the community. Know what that means don't you?
2-You're exposed to the development model. While in a closed-source OS (BeOS), the process is hidden from you. For all you know the (former) BeOS developers could have been wrangling with the same issues as you, but since the majority are never exposed to that. They believe that something mysterious and magical is happening when they go to use their computers.
I think the hardware manufacturers worry too much about information leakage due to drivers. Their worry being real however I think a good solution would be closed source drivers for say 3-5 years after a card is released followed by the release of all specs + driver source. This ensures that older technology can be supported on all systems and for many years to come while at the same time protecting the cutting edge stuff. I'd hate to have Linux have the same problems as windows versions with binary only drivers.
Not necessarily. In the default Sharp install, running Java programs (as one example) will create movable windows that partially obscure programs below them. There is a simple kind of "window manager" behavior going on.
Also, it is completely possible to rearrange file permissions so that Qt on the Zaurus can run as non-root. Why Sharp chose not to do this is difficult to imagine.
100x a faat PC isn't really that much. I wouldn't be such a braggert.
Newer models (sl5600, slc700) run as a non-root user.
A lot of manufacturers aren't supporting the community. Know what that means don't you?
Which community?
You're exposed to the development model. While in a closed-source OS (BeOS), the process is hidden from you. For all you know the (former) BeOS developers could have been wrangling with the same issues as you, but since the majority are never exposed to that. They believe that something mysterious and magical is happening when they go to use their computers.
I don't give a damn. As long as it works.
Don't tell me to use Windows just because the GNOME project isn't capable of tight integration.
Stating on Slashdot that I like cheese since 1997.
IT DEPENDS
IT DEPENDS
IT DEPENDS
Last I checked, if you set our server to unix:0 it didn't use networking. But if you set it to hostname:0 it did.
And besides, INET sockets aren't all that much slower than UNIX sockets. Both are incredibly slow next to no IPC (shared memory).
Some Xservers I thought used shared memory for large objects also. But the commands all go through local IPC for queuing and snychronization anyway.
If you look at Windows, they got an enormous speed boost by making as many APIs as possible run right in the user memory space and making the ones that couldn't do that run in the kernel space.
In other words, Windows has speed thing up to a level where they are going to direct code calls without so much as a context switch. That's where blinding speed comes from. And you get excited that X can be made to not use local return IP sockets?
"I'd hate to have Linux have the same problems as windows versions with binary only drivers."[1]
Hehe. The problem didn't stop with a graphics card, but continues on with a chipset (nForce). The only thing keeping that aspect relatively clean is all the other (open) chipsets out there.
[1] Which simply reenforces my argument that most of the arguments for binary drivers are coming from former windows users. Think about it.
"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.
Yours would have been a fine rant, except...
1-Guess what the day jobs are of some of the X writers are? Uh..hu that's right. You make the same mistake as people do with the kernel people.
2-Your forgetting as one person mentioned in another post, that manufacturers are working against open source writers. When the team at your company of choice is similarly handicapped, then you can talk about superiority.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Anyone who says they're trying to "prevent uninformed comments about X" and then goes on to say X WINDOWS three times in a row (bold face theirs) should NOT get modded up. It's X, or a windowing system called X, not X Windows.
Thank you.
THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT
THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT
THE MEMORY USAGE OF X REPORTED BY `TOP' IS NOT CORRECT
Got it? Good! Stop the nonsense regarding X! Stop trying to throw out the baby with the bathwater.
Network transparency is used by a lot of people. Network transparency does not slow down X locally. Network transparency does not add considerable bloat.
Blah blah blah. Stop the insanity!
Sticking feathers up your butt does not make you a chicken - Tyler Durden
This has nothing to do with Linus accepting or refusing patches. The issue would be if IBM came to Linus and said "Hey Linus we need Linux to work on our big mainframes, but we aren't going to help you or pay you to do that we just want it to work." Would Linus agree to that, probably not. That's what I'm talking about here. In Open Source the users should contribute, and if they don't they shouldn't complain about features lacking or not lacking.
It isn't about wheither or not developers should listen to users (they should) but its about wheither developers should take seriously one person who's screaming "Fundamentally change Linux because I said"
The Anti-Blog
I didn't say that people who like KDE should go to Windows. I told the parent poster to go use Windows if he wanted an OS where the graphical interface is (mostly) dictated to him.
If you like KDE, fine, use KDE, you have that choice. I like a combination of Blackbox with GNOME and KDE apps better, I don't want to be forced to use KDE which was what the parent was suggesting.
The Anti-Blog
I'm well aware of what X has to offer. I was responding to the assertion that Microsoft had somehow failed to deliver with Remote Desktop and Terminal Services. And not only do I not give a shit who did it first, but the software we need to serve doesn't run on Linux, making any comparison academic at best.
irb(main):001:0>
Heh. Of course, there's the whole issue where the high-end open source drivers don't perform nearly as well as the closed sourced ones. ;-)
:(
;-)
This is isn't a problem with open-source, simply the fact that the closed source drivers are better, currently.
Granted, a better kernel interface for this kind of stuff would elminate the whole problem; it shouldn't need porting of a _driver_ between different user-space systems.
(Sure I'll receive flak for this opinion on the AP list now.
Once again I'm glad to have a Matrox card. I had to set up a computer for molecular visualization once (requiring an OpenGL video card), and the NVIDIA cards just weren't working on the cheap OEM hardware. ATIs were pretty good, but the only thing that worked the first time, without a crash, was the Matrox. It's a little bit on the expensive side, but I can run nearly any OpenGL app with the knowledge that it's not going to crash or fill the screen with garbage.
:)
So now that we have transparent windows and shadowed mouse cursors, are we satisfied that all the crucial elements of a desktop operating system are there?
I am no expert on how every layer of a windowing system interacts. I do know however that on exactly the same hardware, if I use XFree86 with the Nvidia drivers, instead of Windows XP/2000/98, the screen takes longer to redraw, applications take longer to load up. XFree86 *FEELS* slower than windows. As long as this happens, average people (like me) will feel reluctant to use *nix as their desktop. Why not take a tip from Apple. It should be possible to have a version of XFree86 that takes full advantage of a modern graphics card. I believe that OS 10.2 uses OpenGL for the entire interface?
--------- I have no signature
"Oh sure there's XDirectFB, but 1) doesn't that make the whole point of ditching X a joke and put us right where we started? 2) does it support important extensions like Xrender, Xshm and XVideo?"
No.
You are missing the point. The point is to directly render all local desktops. Why on earth would you indirectly render your local desktop just because you are too lazy to implement a direct rendered model? That is the objective of DirectFB:
To implement the X protocol OVER a direct rendered local model, rather than implementing local models over X's indirect model. (note, this is how X clients work in win32))
The problem with all you X zealots that think you are god and all knowing is that you actually don't know everything. And you have proven this in your post.
Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
Signals and semaphores can only send a few bits of meaningful info.
Qualify that to "unix/linux semaphores" and you may be right. But not in general.
There is a variant of semaphores called "communicating semaphores" that explicitly manages queues - of messages waiting for processes, or processes waiting for messages. They can be impelmented to handle messages of arbitrary size, and yet still perform all the other primitive operations needed in an OS kernel.
With a single mechanism handling interprocess communication, interrupt handler/driver communication, producer/consumer data streaming, mutual exclusion, signaling, memory and other resource allocation and arbitration, you can build a real-time OS kernel with actor-based applications in a HYSTERICALLY tiny amount of code.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
X maps the entire video ram. So if you have an 8MB card, then 8MB of X's supposed memory usage is actually mapped video ram. X can use the remaining 5 MB (eg 3MB used for display from your example) of video ram to store pixmaps, etc.. (google for XAA - X acceleration architecture iirc). If you have a 32MB card, then X will be at least 32MB in size, if you have a super duper 128MB card, X will be at least 128MB in size - just because of the VRAM mapping.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
Actually, modern glibc uses mmap() instead of sbrk() to allocate memory in many cases. mmap()ed segments get returned to the system at munmap() time.
DNA just wants to be free...
You misread something as having "FBI" in it.
"DirectFeds." You're right. That is hilarious and warranted posting about it.
"Sufferin' succotash."
The main problem is that 3D is a whole different kettle of fish than 2D. The 'nv' 2D driver is 80kb compiled. The NVIDIA 3D driver is about 6MB of code, split up over a 400K X driver, a 5MB OpenGL library (libGL is vendor specific in the ICD architecture) and a 400K GLX driver. It's a whole lot more code, it's very hardware-specific, and it's a rather specialized field. The field of kernels is something else entirely. Kernel coding is a well understood field of computer science, and there are lots of OSS kernel developers who have a lot of experience in academia and the commercial industry. There is a reason why none of the DRI drivers are particularly competitive with the native Windows versions, while NVIDIA's Linux driver is pretty much equal between the two.
A deep unwavering belief is a sure sign you're missing something...
This isnt true, using the QPE libraries you only see one app at a time, but it is possible to create your apps in windowed mode ( try showing your application using QWidget::show() and not QWidget::showMaximized()). Most QPE applicaions specifically show the window as being maximized.
Also, it doesn't have to run everything as root, but it's the easiest way to do things. QT/e needs to be able to read and write to the device files for your mouse and framebuffer, but otherwise it is doable. What it does have problems with is having apps running as different users on the same display, although it is an easy enough hack to add support for running an app as root while logged in as a different user.
I believe that OS 10.2 uses OpenGL for the entire interface?
>>>>>>>>>
This is probably the millionth time I've said this. I feel like "Celebrity Jeopardy" skit where Keanu Reeves keeps saying "whoa, I know kung-fu" and Alex Trebek keeps saying "for the last time Mr. Reeves, no you don't!"
Quartz "Extreme" does not use OpenGL for "the entire interface." It's right in Apple's Siggraph paper, with pretty pictures and everything. Quartz still uses the CPU to render graphics into memory buffers. The only time OpenGL gets used is when those buffers are composited together to get the final picture. This is a step up from the previous software compositor, but other windowing systems don't even have the extra compositing step, which exists only to support the transparency and genie effects.
A deep unwavering belief is a sure sign you're missing something...
"There is a reason why none of the DRI drivers are particularly competitive with the native Windows versions, while NVIDIA's Linux driver is pretty much equal between the two."
Yes, and I will tell you the same thing I told him. Some of the people who practice video driver writing are some of the same people who do it professionally. Now why do you keep ignoring that point?
"There is a reason why none of the DRI drivers are particularly competitive with the native Windows versions, while NVIDIA's Linux driver is pretty much equal between the two."
And the point you ignored (just like last time) is that the people who are writing the drivers are working under an artificial barrier that their counterparts are not. Have you ever reverse engineered a large binary before? How about hardware?
"hardware accelerated OpenGL is fast enough on linux."
:-P
Yes, even when using Perl to drive it
Thanx about the X11perf tip, very cool.
:)
:0.0
:0.0
1 Ghz AMD Thunderbird, Nvidia Geforce 3 Ti 200, 512 MB RAM (about 128 MB used, the rest currently in use as filecache).
XMMS was playing in the background
x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40100000 on
from null
Fri May 2 00:24:53 2003
Sync time adjustment is 0.0594 msecs.
30000 reps @ 0.1755 msec ( 5700.0/sec): 500x500 rectangle
30000 reps @ 0.1751 msec ( 5710.0/sec): 500x500 rectangle
30000 reps @ 0.1745 msec ( 5730.0/sec): 500x500 rectangle
30000 reps @ 0.1746 msec ( 5730.0/sec): 500x500 rectangle
30000 reps @ 0.1742 msec ( 5740.0/sec): 500x500 rectangle
150000 trep @ 0.1748 msec ( 5720.0/sec): 500x500 rectangle
Woah!
x11perf - X11 performance program, version 1.5
The XFree86 Project, Inc server version 40100000 on
from null
Fri May 2 00:26:51 2003
Sync time adjustment is 0.0620 msecs.
1200 reps @ 5.2156 msec ( 192.0/sec): ShmPutImage 500x500 square
1200 reps @ 5.2064 msec ( 192.0/sec): ShmPutImage 500x500 square
1200 reps @ 5.2098 msec ( 192.0/sec): ShmPutImage 500x500 square
3600 trep @ 5.2106 msec ( 192.0/sec): ShmPutImage 500x500 square
Wow!
First some background. Some former co-workers who were resently layed off, along with myself, and some who were not, but see no futur, are getting ready to start writing crossplatform internet based games. We will eventuly attempt producing a Linux based game consol. As I use to fill the roll of Software Architect, and am the most familiar with Linux and graphics issues, I have been tasked with doing a preliminary design. I was investigating DirectFB. My question is, how suitable is SDL for imbeded applications? I have more questions, but need to get back to working on my resume. Obviously, outside employment will be needed to bring in money untill this project becomes profitable ( looking at years here). So no more wasting time on /.!
You can get the ck-patches against 2.4.20 if you want the interactivity updates for a stable kernel.
Are there plans to bring dual displays to DirectFB. I use it on all my systems except my main one since it's got dual displays.
You are entitled to your opinion of what should be in the open source world. I'm not trying to change your mind.
What I am pointing out is that successful projects do keep their "customers" in mind. If a security hole is discovered in Apache, by your logic, nobody can demand a patch, much less an immediate patch. That's fine, but Apache wouldn't be successful if things worked that way.
Also, it's easy to say "you should help", but the nature of software is that it is usually many times harder for anybody else to fix something than the original author. This is even more true with bigger projects. The fix from the original author is more likely to fit in well with the overall design, and be less buggy.
So I'm not arguing that you should listen to every random idiot with an opinion. However, your statement leans too far the other way, probably resulting in software that only developers will use. The freedom inherent in open source software permits higher quality software, but IMHO not if you ignore the end user too much.
I would gladly give you a +5 informative" if it was in my power.. Not today.
Yes, some of the people writing video drivers are some of the same people doing it professionally. I just learned on xwin.org today that one of those people is Mark J. who works on XAA (among other things) and also works at NVIDIA. However, I'll assert that the number of experienced 3D driver writers working on XFree are rather small compared to the number of dedicated driver guys at ATI and NVIDIA.
Also, AFAIK, none of the DRI drivers are reverse engineered. The specs of the ATI, Matrox, 3dfx, and i8xx chips are publically available. Heck, I've read the Matrox and 3Dfx docs myself.
A deep unwavering belief is a sure sign you're missing something...
I look at it this way: who has the resources and expertise to best disassemble, interpret and live-hardware-debug your video card? Is it your competitors or the OSS developer-in-the-street? How many OSS freaks do you know carry digital scopes and logic analysers able to resolve and capture into the gigahertz range?
So by hiding the driver source and card details they're taking away advantages from their customers, not their competitors.
Your plan is a vast improvement on what we have now, but really the paranoid lawyers controlling the chipmakers need a heavy dose of reality.
Exposing details of their chips (especially for something like VIA's Savage4-derived horrors but this applies to ATI and nVidia just as well) isn't going to help their competitors very much at all, but it will help their customers lots, and a helped customer is a happy, loyal customer.
Are you listening, nVidia?
Got time? Spend some of it coding or testing
At what level? SDL? GGI? GTK? Qt? wxWindows? KPart? Six of one, half a dozen of the other, perhaps you're spoilt for choice?
Got time? Spend some of it coding or testing
QUARTZ FOR MAC OS X
T ec hnologies/graphics/Quartz2D/quartz2d.html
http://developer.apple.com/techpubs/macosx/Core
" Yes, some of the people writing video drivers are some of the same people doing it professionally. "
He finally admits it. I swear it's like pulling teeth with you some days.
"However, I'll assert that the number of experienced 3D driver writers working on XFree are rather small compared to the number of dedicated driver guys at ATI and NVIDIA."
Two things. One neither one of us knows exactly how many people either have on their driver teams, so quanitative corparisons are going to be a bit meaningless. Two the XFree team has a bigger target than the focused team of either Nvidia or ATI. I rather doubt that "Team Nvidia" or "Team ATI" would do much better if they had to support as many cards as the XFree team does, at the pace that they do.
"Also, AFAIK, none of the DRI drivers are reverse engineered. The specs of the ATI, Matrox, 3dfx, and i8xx chips are publically available. Heck, I've read the Matrox and 3Dfx docs myself."
That's true in the majority, but as another poster pointed out, a lot of the hard work that went into opening up is being undermined by people who simply accept a binary status quo, and take a whole blaise attitude to the situation.
Even for those that are open, they're not so open that there isn't an aspect that doesn't have to be figured out the hard way (i.e TV out, Macrovision bypass fears).
AF_UNIX sockets work just like AF_INET sockets once you bind(2) that file handle! That's not "nothing to do"! That's PLENTY to do with AF_INET! What I'm talking about is a facility meaning it makes something easier. It's not just a bonus, it's the whole point! If you do dumb things like program AF_UNIX sockets without thinking about network transparency, some day you will be cursed by the guy who has to hack in all the missing network-byte-order stuff, etc..in order to get it to work over future-speed networks that are faster than the memory bus on your computer.
One thing you have to tackle when you get into the Unix world is the concept that users and programmers are discrete sets. In Unix, the greater the union of those two sets, the better! If you're a programmer, you should "think user." If you're a user, you should "think programmer."
Oh, and BTW your spam (in the original Usenet sense of repetition)
does not contribute to the reasoning of your argument.--- Nothing clever here: move along now...
Bingo! Finally someone who gets what I've been saying for the past month. There's a little secret to the business world. Companies watch competitors, and no I'm not just talking what Wall Street puts out. This is why the whole "Got secrets?" argument falls apart. And no, one doesn't have to slip it into the stream. There are sublabs if you will that keep tabs. Hell there's entire companies that do this kind of work. The "/." crowd never ceases to amaze me with their ignorance (ugly it may sometimes be) about the underbelly of the world.
Live with this: /. is probably not very different from Joe Public. (-:
Got time? Spend some of it coding or testing
No, it's you anti-X zealots who think you know everything and blame everything bad in the world on X. It's also called elitism: you think you're better just because you're against X. Well, you're not.
Tip: apply the desktop/interactivity patches for your kernel: http://members.optusnet.com.au/ckolivas/kernel/
Before I did this, my Linux desktop was indeed a bit slower and less responsive than Windows. After I applied the patches, it became just as fast as Windows, and in some areas even faster. Try it out, you will notice the difference.
As for applications taking longer to load, I don't know why that happens, but app loading time has got nothing to do with the windowing system.
But the main problems are in GNOME and KDE, because fvwm/twm/BlackBox/WindowMaker/Xfce are incredibly fast compared to them. GNOME and KDE are what need to be optimized further.
It's strange, I installed a RedHat 7.3 desktop for a friend and he said he can't notice any difference in speed compared to Windows 98 (even without the kernel patches).
I thought ATI only released specs under NDA to DRI programmers.
Pardon me, but I don't think I was the original poster you were so mad at. I never denied there were professionals working on 3D.
A deep unwavering belief is a sure sign you're missing something...
I never said i was against X, idiot.
I use it every day for remote desktops. XFree86. I also use it locally on Linux. Every day.
I just happen to know (unlike you) that its not optimal for local display. There are better solutions out there that are faster, more efficient, and more suited for local desktop use. Sure, XFree86 does the job. But far from optimal. The competition has proven this. XFree86 was designed to display remotely. That is what the entire X protocol is used for. It just so happens that you can use the same principles to display locally
Until you realize that XFree86 is slower than most 2d desktop rendering systems when used locally, you will be blind of the facts. Its as simple as that.
Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
Nope, YOU are blind of the facts. Everything you say is just theory. In theory, X is slower because it was designed for remote displays. But benchmarks do not lie! My benchmarks clearly proved that XFree86 is just as fast as Windows on my system. The numbers say so! If you mod down hard benchmark numbers then you are ignorant to the reality.
What could stop one from writting an application that mediates between an API and a network protocol? Is NFS limited to those operating systems designed with "network transparent" filesystem APIs? If your beliefs on what is technically possible and what isn't are true, then how does OSX's remote GUI work? I'm "thinking hard" right now, but still can't figure out why your post needed anything other than the third paragraph. I guess I must be one of those "morons".
Directfb is a great api. it can even be usefull because SDL supports it. so it should not be a to big problem to have a game SDL-only game like tuxracer ( if i recall right then ut2003 was SDL-only to) by SDL only i mean the program is not using any X-server api's. running a game directly from the console has the same big adventage as running a game on a "gaming console" ( ala gamecube ). the less progs like kde, gnome with lots and lots of processes running that might trigger a crash the better. console only gaming could definitly rule for the serious hardcore gamers.
I know that this discussion has become too old for my post to really hit this conversation, but this is such a ridiculous claim that I can't let it slide. I have two machines here at home. One dual boots Debian and W2K. The other dual boots Debian and OSX (Jaguar). If there is any difference in GUI performance between X11 and W2K I can't detect it. On the Powerbook I find OSX to be so irritatingly slow in comparison to XFree86-Enlightenment-GNOME that I stopped booting into it. What makes this comparison even less favorable to OSX is that XFree86 is running on the framebuffer. If you want to advocate alternatives to X11 then do so. I'm already with you in spirit. If you think X11 has problems then state them. I'll listen. But claiming that XFree86 is slow compared to the Microsoft or Apple display systems flys in the face of my daily experience. In the case of OSX especially, I find your comparative claim so ludicrous that I don't believe that you believe it.