"And your point about stallman is probably not a good example. He is one of the very few developers that are well known and have got a big reputation in the opensource community."
Well if you look at Slashdot, then I'd say he has a big reputation of being the man who gets most flamed at! Just look at the Slashdot article about the GNU/Linux FAQ. It generated well over 1000 comments, of which 95% are trolls, flames and personal insults towards RMS. A lot of them even got modded up to +5 Insightful!
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.
It's already been done. Locally, XFree86 uses shared memory for transporting pixmaps, and Unix Domain Sockets for communication. No TCP/IP is involved.
Unix Domain Sockets on Linux are heavily optimized. They're just as fast as shared memory.
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).
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.
"And besides, INET sockets aren't all that much slower than UNIX sockets. Both are incredibly slow next to no IPC (shared memory)."
This is not true. First, shared memory *is* a form is IPC. If it isn't IPC it wouldn't be called "shared". Second, on Linux, Unix Domain Sockets are just as fast as shared memory. There has been an attempt to make XFree86 communicate entirely using shared memory. But it turned out that Linux's Unix Domain Socket implementation is just too efficient and that there is almost no performance gain.
"Some Xservers I thought used shared memory for large objects also."
Like XFree86...
"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."
See my other posts. I did a benchmark. On my machine, Windows is NOT faster than XFree86 when it comes to pure frames per second! My benchmark says they're both just as fast. The main bottleneck is and remains to be drivers. The XFree86 driver for ATI Rage 128 is good, so I get the same performance as in Windows.
"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.
"Crowd: X is bloated 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-fri endly-Windows-XP has millions of code too.
"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-yo u-no-matter-how-uninformed-we-are"-zealot.
"I mean, sure, network-transparency is wonderful but how many people are really using it? 1 in 20?"
Multiply that by 1 million and you'll get 1.000.000 in 20.000.000. Don't mark something down as "useless" bloat just because only what seems to be a minority in percentages use it. Even if only 1% use network transparency, if there are 500.000.000 computer users then there are still 5 million people who need network transparency!
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.
Anime *is* originated in the US. It's called cartoons.
But honestly. Anime isn't cool because it's not from the US, it's cool because it's cool.
- Although anime usually has less animation than US cartoons, the animation is much, much higher quality. Quality over quantity. This is usually only true for TV series (the animators have to produce 1 episode per week). OAVs and movies contain much more (and smoother) animations. Exceptions: Rurouni Kenshin (TV series has beautiful and smooth animation), Full Metal Panic (perfect integration of 3D graphics and hand-drawn animation, unlike *cough* Marvel).
- Most of the voice actors (and actresses! especially the actresses!) are extremely talented. Much, much more than most US voice actors. You can actually hear emotions in their voices. And the female voices usually sound beautiful. Most of the voices suite the personality of the character very well. I've never seen any dub with voices that's as good as it's sub counterpart.
- The story, plot and dialog. Most of the anime that are targeted for older audiences (no, not pr0n!) have a very good story and plot, much more than US cartoons. And instead of pumping everything into your head like Marvel or Disney does, some of them actuall make you think and let you decide what happened (NGE, Wolf's Rain, etc.).
Of course there are exceptions but generally speaking, the above poitns are correct.
Also keep in mind that I'm talking about modern anime, not 15 year old shows like DBZ! Honestly, go download some modern fansubs and behold the pure quality the animation, voices and story.
Yeah right. AAC support on MP3 players? Since when? Can you point out one player? Because I've never seen them. Ogg Vorbis also has portable player support. Sharp Zaurus can play Ogg Vorbis files.
You say Ogg is "geeky". What is so geeky about it? It's just yet another audio codec. It isn't geeky. You want to believe it's geeky so you think it's geeky. Technology is just technology.
"that means Ogg is screwed!"
Oooh! And so is AAC!
You make it sound as if AAC is "more widely supported" than Ogg. That is not true. - Your grandma doesn't know what AAC is either! - Portable player support is no better than Ogg! - Unlike Ogg, AAC is clumbered with patens and licensing fees. This will scare away many small companies.
Face it, AAC is not more widely supported than Ogg! People only make Ogg look worse than AAC just because Ogg is open source and because AAC is backed up by a company.
"(for the uninitiated, don't run that! ".." matches ".*" you know...)"
Then you are using the wrong system. Try doing rm.* on a GNU/Linux system: [bash@izumi test]$ rm.* rm: cannot remove `.' or `..' rm: cannot remove `.' or `..'
"Intel's compiler brags that it is totally compatible with gcc and gives a 30% speed increase to the final result on an Intel processor."
That's only true for pre-GCC 3.1 releases. GCC 3.2 can produce code that rivals that of Intel C++. GCC 3.1 and 3.2 contain lots and lots of x86 optimization improvements.
I have nothing against eyecandy. I do have something against eyecandy that harm productivity. In this case, translucency. Translucent menus make the menu labels unreadable. Translucent terminals make the terminal text unreadable. That's what I call useless eyecandy.
More power to us? How? In what way? I would hardly call translucent windows and shadows "more power", it's just eyecandy and doesn't improve my productivity.
Quartz Extreme uses OpenGL acceleration for window compositing, but the actual drawing inside the window is still rendered in software. Heck, when it comes to raw drawing speed, Quartz is actually slow.
I don't know about you but when I'm reading a webpage, I want to concentrate on the webpage, not everything below it. When I'm writing a report, I want to concentrate on my word processor, not all the windows below it.
Translucent windows is eyecandy and good for demonstrations, but that's pretty much it. Other than that, they're usability nightmares and harm productivity.
Why do we need a "3D-accelerated desktop" or "translucent windows" in order to "succeed on the desktop"? Win95/98/ME didn't have either. Were they ready for the desktop? People said they are. Translucent windows are only eyecandy and can actually decrease productivity. When I'm typing a report I want to concentrate on my report, not all the windows below my word processor!
Everybody seems to be obsessed with all this "3D-accelerated desktop" stuff but IMHO it's all overrated.
Using OpenGL will not automatically make everything faster. Heck, I wouldn't be surprised if some things become slower. OpenGL is good for 3D stuff, but sucks for 2D stuff. Ever tried blitting in OpenGL? Slooooooooow. And guess what? Most applications use 2D drawing primitives.
The biggest performance bottlenecks are, and have always been: 1) the driver 2) the kernel. 2 has already been addressed (my system flies with these patches; it's even faster than Windows!). The upcoming 2.6 kernel will be amazing. 1 remains a problem. X's architecture doesn't cause the slowness, it's all in the driver! If the driver doesn't implement all OpenGL features then you'll still be stuck with slow drawing speed (or maybe even slower, since emulating OpenGL is slow beyond imagination. ever tried running TuxRacer in plain non-accelerated Mesa?)
Slashdot Mirror
"And your point about stallman is probably not a good example. He is one of the very few developers that are well known and have got a big reputation in the opensource community."
Well if you look at Slashdot, then I'd say he has a big reputation of being the man who gets most flamed at!
Just look at the Slashdot article about the GNU/Linux FAQ. It generated well over 1000 comments, of which 95% are trolls, flames and personal insults towards RMS. A lot of them even got modded up to +5 Insightful!
Not to mention that kids usually know their computer better than their parents do.
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.
It's already been done. Locally, XFree86 uses shared memory for transporting pixmaps, and Unix Domain Sockets for communication. No TCP/IP is involved.
Unix Domain Sockets on Linux are heavily optimized. They're just as fast as shared memory.
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).
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.
Binary compatible != kernel module compatible.
A big part of DirectFB is implemented in kernel space.
"And besides, INET sockets aren't all that much slower than UNIX sockets. Both are incredibly slow next to no IPC (shared memory)."
This is not true.
First, shared memory *is* a form is IPC. If it isn't IPC it wouldn't be called "shared".
Second, on Linux, Unix Domain Sockets are just as fast as shared memory. There has been an attempt to make XFree86 communicate entirely using shared memory. But it turned out that Linux's Unix Domain Socket implementation is just too efficient and that there is almost no performance gain.
"Some Xservers I thought used shared memory for large objects also."
Like XFree86...
"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."
See my other posts. I did a benchmark. On my machine, Windows is NOT faster than XFree86 when it comes to pure frames per second! My benchmark says they're both just as fast.
The main bottleneck is and remains to be drivers. The XFree86 driver for ATI Rage 128 is good, so I get the same performance as in Windows.
"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.
But does it support important extensions? Xrender? Xvideo? Xshm?
"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
"I mean, sure, network-transparency is wonderful but how many people are really using it? 1 in 20?"
Multiply that by 1 million and you'll get 1.000.000 in 20.000.000.
Don't mark something down as "useless" bloat just because only what seems to be a minority in percentages use it.
Even if only 1% use network transparency, if there are 500.000.000 computer users then there are still 5 million people who need network transparency!
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.
Anime *is* originated in the US. It's called cartoons.
But honestly. Anime isn't cool because it's not from the US, it's cool because it's cool.
- Although anime usually has less animation than US cartoons, the animation is much, much higher quality. Quality over quantity.
This is usually only true for TV series (the animators have to produce 1 episode per week). OAVs and movies contain much more (and smoother) animations. Exceptions: Rurouni Kenshin (TV series has beautiful and smooth animation), Full Metal Panic (perfect integration of 3D graphics and hand-drawn animation, unlike *cough* Marvel).
- Most of the voice actors (and actresses! especially the actresses!) are extremely talented. Much, much more than most US voice actors. You can actually hear emotions in their voices. And the female voices usually sound beautiful. Most of the voices suite the personality of the character very well. I've never seen any dub with voices that's as good as it's sub counterpart.
- The story, plot and dialog. Most of the anime that are targeted for older audiences (no, not pr0n!) have a very good story and plot, much more than US cartoons. And instead of pumping everything into your head like Marvel or Disney does, some of them actuall make you think and let you decide what happened (NGE, Wolf's Rain, etc.).
Of course there are exceptions but generally speaking, the above poitns are correct.
Also keep in mind that I'm talking about modern anime, not 15 year old shows like DBZ! Honestly, go download some modern fansubs and behold the pure quality the animation, voices and story.
Yes, it only tells you that most consumer PC sound hardware sucks.
Yeah right. AAC support on MP3 players? Since when? Can you point out one player? Because I've never seen them.
Ogg Vorbis also has portable player support. Sharp Zaurus can play Ogg Vorbis files.
You say Ogg is "geeky". What is so geeky about it? It's just yet another audio codec. It isn't geeky. You want to believe it's geeky so you think it's geeky. Technology is just technology.
"that means Ogg is screwed!"
Oooh! And so is AAC!
You make it sound as if AAC is "more widely supported" than Ogg. That is not true.
- Your grandma doesn't know what AAC is either!
- Portable player support is no better than Ogg!
- Unlike Ogg, AAC is clumbered with patens and licensing fees. This will scare away many small companies.
Face it, AAC is not more widely supported than Ogg! People only make Ogg look worse than AAC just because Ogg is open source and because AAC is backed up by a company.
AAC is no different. Ask your neighbour what AAC is. It's very likely that he's never even heard of it.
"(for the uninitiated, don't run that! ".." matches ".*" you know...)"
.* on a GNU/Linux system: .*
Then you are using the wrong system. Try doing rm
[bash@izumi test]$ rm
rm: cannot remove `.' or `..'
rm: cannot remove `.' or `..'
"Intel's compiler brags that it is totally compatible with gcc and gives a 30% speed increase to the final result on an Intel processor."
That's only true for pre-GCC 3.1 releases. GCC 3.2 can produce code that rivals that of Intel C++. GCC 3.1 and 3.2 contain lots and lots of x86 optimization improvements.
I have nothing against eyecandy. I do have something against eyecandy that harm productivity. In this case, translucency.
Translucent menus make the menu labels unreadable. Translucent terminals make the terminal text unreadable. That's what I call useless eyecandy.
And the only thing we have to do is to wait until that hardware becomes available for x86?
More power to us? How? In what way? I would hardly call translucent windows and shadows "more power", it's just eyecandy and doesn't improve my productivity.
Quartz Extreme uses OpenGL acceleration for window compositing, but the actual drawing inside the window is still rendered in software.
Heck, when it comes to raw drawing speed, Quartz is actually slow.
I don't know about you but when I'm reading a webpage, I want to concentrate on the webpage, not everything below it.
When I'm writing a report, I want to concentrate on my word processor, not all the windows below it.
Translucent windows is eyecandy and good for demonstrations, but that's pretty much it. Other than that, they're usability nightmares and harm productivity.
Why do we need a "3D-accelerated desktop" or "translucent windows" in order to "succeed on the desktop"?
Win95/98/ME didn't have either. Were they ready for the desktop? People said they are.
Translucent windows are only eyecandy and can actually decrease productivity. When I'm typing a report I want to concentrate on my report, not all the windows below my word processor!
Translucency is nice but it's not a requirement.
Everybody seems to be obsessed with all this "3D-accelerated desktop" stuff but IMHO it's all overrated.
Using OpenGL will not automatically make everything faster. Heck, I wouldn't be surprised if some things become slower. OpenGL is good for 3D stuff, but sucks for 2D stuff. Ever tried blitting in OpenGL? Slooooooooow. And guess what? Most applications use 2D drawing primitives.
The biggest performance bottlenecks are, and have always been: 1) the driver 2) the kernel.
2 has already been addressed (my system flies with these patches; it's even faster than Windows!). The upcoming 2.6 kernel will be amazing.
1 remains a problem. X's architecture doesn't cause the slowness, it's all in the driver! If the driver doesn't implement all OpenGL features then you'll still be stuck with slow drawing speed (or maybe even slower, since emulating OpenGL is slow beyond imagination. ever tried running TuxRacer in plain non-accelerated Mesa?)