I use nvidia's proprietary binary video drivers, which share the lion's share of their code between the Windows and Linux video driver implementations. So yes, in a way they're the same driver.
Nvidia's linux support is pretty good, and the raw performance of the driver (under say, SDL, or DirectFB) on Linux can be shown to be almost identical to it's performance under Windows.
Yet strangely the many layers between X apps and the display architecture manages to slow down the GUI. (app, widget libraries, display managers, window managers, session managers, shared memory implementations and/or network layers, video drivers,... can you say "bloat"?)
X *can* do fast graphics, just look at SDL running full screen with OpenGL acceleration -- it's a shame X isn't able to fully utilise this speed when running applications.
I know this. It's a feature -- who wants to look at blurry fonts all the time? But your post doesn't change the fact that AA fonts under Windows do not seem to impact the general responsiveness of the system. So why should they do so under X?
If my display hardware can shunt polygons and surfaces around with hardware alpha channels, bi- and tri-linear filtering, and my cpu is capable of rotozooming entire screenfuls of pixels with bilinear filtering, then I think it can probably cope with a few anti-aliased fonts. Especially as there are so many clever tricks that can be used to accelerate this process.
To highlight this point, I am posting this message using 600% zoom using Opera under Win32;-)
Rubbish. On my home machine, Win2K is fast, X is slow. I'll address your points individually:
1.Slow anti-aliased fonts.
I have anti-aliased fonts in Windows. It ain't slow. If X provided a decent standardised AA fonts interface that was correctly integrated into it's core functionality, then this wouldn't be a problem. AA font rendering should not be that CPU or GPU intensive. It's been around for years -- it's not THAT hard a problem. If a PDA can do sub-pixel font rendering, then a Pentium III shouldn't have much of a problem.
2. Some video card drivers are slow.
Agreed, but most of the intensive rendering on my machine is using the same driver (nvidia). If pixmaps didn't have to be uploaded to the server, then perhaps there wouldn't be a problem. If uploading to remote servers was transparent, and handled by the windowing system itself, then it shouldn't be a problem.
4. Window managers do dumb things, like excessively redrawing apps when you switch virtual terminals.
Yes this does happen. But have you ever compared the number of redraws under X, compared to the number of redraws under Windows by running on a slow PC? Windows does much more redrawing (how many times does it really need to draw my desktop icons every time I press Win-M, for example?!) yet manages to run its display faster than X on most systems. Again, eye candy is fast on Windows, slow on X, on the same machine with the same drivers and the same video card.
5. Poorly implemented eye candy.
If X had decent alpha-channel support, decent pixmap caching and hardware accelerated shading or speedy direct rendering, then we wouldn't need poorly-implemented eye candy hacks.
C'mon, I like X, and it's got a lot going for it; but I can't pretend it's not a slow resource hog. X can't even blit a window around the screen at full speed. And that isn't my video card slowing it down(my card can do this in it's sleep), or my drivers(because I can do it blazingly fast using GGI, DirectFB, or SDL): it's X itself.
In short, I think all of these concerns could (and should) be addressed by improving the underlying X architecture. The app layer needs to be brought closer to the hardware display layer.
And while we're on the subject, can't somebody come up with a decent accelerated video display architecture that works on the console and under X. Sure, it can be done: but do you use GGI, KGI, SDL, DGA, X11, DirectFB, plain framebuffer, svgalib,... ?? Surely somebody sees the need for a unified linux display architecture? Would save a hell of a lot of heartache writing video drivers..., not to mention choosing APIs...!
I agree. In my previous job my main working machine was a Win2k box with PuTTY and a commercial X server installed. It's actually a very nice environment to work in -- I could use Explorer to administer and manage files on my remote linux server, editing PHP code with my favourite Win text editor (ConTEXT) and at the same time using Outlook (not my fave, but the company standard), and develop Win32 code. Best of both worlds. Plus I got to wow all my surrounding Windoze-only colleagues with impressive looking KDE themes!:)
Without X's network transparency, I'd be upstairs on the linux box half the time, separated from colleagues, and reducing my efficiency.
The only downside -- having to walk upstairs to change CDs occasionally!:-)
However, I also see the need for a slimmer, leaner, meaner X, with a fast (perhaps even kernel-level?) direct rendering system, with less cruft. I have a lowly PIII 550 256Mb at home, and X is a bit of a pig; whereas Win2K's GUI just whizzes along nicely.
I don't necessarily think that network transparency + a fast GUI are mutually exclusive. Surely it's possible to come up with a high-speed rendering and input API that could be controlled remotely via a swappable.so or something? Kind of a remotely-controlled 'layers.library' with locally-cached pixmaps for icons, etc?
I can envisage something like an OpenGL-like pipeline, with a serialised command input, that could be streamed to a specialised hardware accelerated layer on the local machine, or via network to a remote display server? The remote server could afford to be quite minimal in this scenario - a glorified video driver with support for input devices. Surely most of the code necessary for a prototype of this system is already out there?
Don't forget that once you've downloaded and played that Britney MP3, thereby activating the hidden worm, the worm can then go ahead and infect all of your other MP3's, so anyone who downloads ANY of your MP3's would be infected. The worm could then repeat this on the machines of those who download from you... exponential growth. So, theoretically, all you'd need to do is release a single infected Britney MP3, (or better still, a hundred or so of the most popular tracks) and within days you would have infected huge numbers of hosts and MP3 files.
Assuming that this type of exploit is possible in the first place, the potential for infestation on P2P networks would be ENORMOUS. But could that amount of activity (file modifications, changing checksums and file sizes, suspicious packets & requests) go unnoticed for any length of time?
I'll believe it when I see it.
Danger, Will Robinson! In the UK, there are indeed many lawyers and law firms that advertise "no win, no fee"... But be careful! While it's true that if you lose you don't have to pay your lawyer's fee, you WILL still have to pay your opponent's legal fees, and any damages they win. "no win, no fee" is not some kind of magic insurance against legal costs, as might be implied by certain TV adverts!! (From what I am told, I believe a similar situation exists in the US too, except that such services are advertised more widely and aggressively).
Why don't they make it illegal to steal mobile phones in the first place? Surely that will stop the criminals!
Oh, wait, they already thought of that...:-)
Arrrrrrghghgh!! When are people going to learn that making else something illegal doesn't stop criminals from doing something that's already illegal in the first place? They're CRIMINALS for bob's sake!
Slashdot Mirror
I use nvidia's proprietary binary video drivers, which share the lion's share of their code between the Windows and Linux video driver implementations. So yes, in a way they're the same driver.
Nvidia's linux support is pretty good, and the raw performance of the driver (under say, SDL, or DirectFB) on Linux can be shown to be almost identical to it's performance under Windows.
Yet strangely the many layers between X apps and the display architecture manages to slow down the GUI. (app, widget libraries, display managers, window managers, session managers, shared memory implementations and/or network layers, video drivers,... can you say "bloat"?)
X *can* do fast graphics, just look at SDL running full screen with OpenGL acceleration -- it's a shame X isn't able to fully utilise this speed when running applications.
I know this. It's a feature -- who wants to look at blurry fonts all the time? But your post doesn't change the fact that AA fonts under Windows do not seem to impact the general responsiveness of the system. So why should they do so under X?
;-)
If my display hardware can shunt polygons and surfaces around with hardware alpha channels, bi- and tri-linear filtering, and my cpu is capable of rotozooming entire screenfuls of pixels with bilinear filtering, then I think it can probably cope with a few anti-aliased fonts. Especially as there are so many clever tricks that can be used to accelerate this process.
To highlight this point, I am posting this message using 600% zoom using Opera under Win32
It's wrong to blame X for slowness.
Rubbish. On my home machine, Win2K is fast, X is slow. I'll address your points individually: 1 .Slow anti-aliased fonts.
I have anti-aliased fonts in Windows. It ain't slow. If X provided a decent standardised AA fonts interface that was correctly integrated into it's core functionality, then this wouldn't be a problem. AA font rendering should not be that CPU or GPU intensive. It's been around for years -- it's not THAT hard a problem. If a PDA can do sub-pixel font rendering, then a Pentium III shouldn't have much of a problem.
2. Some video card drivers are slow.
Agreed, but most of the intensive rendering on my machine is using the same driver (nvidia). If pixmaps didn't have to be uploaded to the server, then perhaps there wouldn't be a problem. If uploading to remote servers was transparent, and handled by the windowing system itself, then it shouldn't be a problem.
4. Window managers do dumb things, like excessively redrawing apps when you switch virtual terminals.
Yes this does happen. But have you ever compared the number of redraws under X, compared to the number of redraws under Windows by running on a slow PC? Windows does much more redrawing (how many times does it really need to draw my desktop icons every time I press Win-M, for example?!) yet manages to run its display faster than X on most systems. Again, eye candy is fast on Windows, slow on X, on the same machine with the same drivers and the same video card.
5. Poorly implemented eye candy. If X had decent alpha-channel support, decent pixmap caching and hardware accelerated shading or speedy direct rendering, then we wouldn't need poorly-implemented eye candy hacks.
C'mon, I like X, and it's got a lot going for it; but I can't pretend it's not a slow resource hog. X can't even blit a window around the screen at full speed. And that isn't my video card slowing it down(my card can do this in it's sleep), or my drivers(because I can do it blazingly fast using GGI, DirectFB, or SDL): it's X itself.
In short, I think all of these concerns could (and should) be addressed by improving the underlying X architecture. The app layer needs to be brought closer to the hardware display layer.
And while we're on the subject, can't somebody come up with a decent accelerated video display architecture that works on the console and under X. Sure, it can be done: but do you use GGI, KGI, SDL, DGA, X11, DirectFB, plain framebuffer, svgalib, ... ?? Surely somebody sees the need for a unified linux display architecture? Would save a hell of a lot of heartache writing video drivers..., not to mention choosing APIs...!
Don't ask for much, do I? ;-)
I agree. In my previous job my main working machine was a Win2k box with PuTTY and a commercial X server installed. It's actually a very nice environment to work in -- I could use Explorer to administer and manage files on my remote linux server, editing PHP code with my favourite Win text editor (ConTEXT) and at the same time using Outlook (not my fave, but the company standard), and develop Win32 code. Best of both worlds. Plus I got to wow all my surrounding Windoze-only colleagues with impressive looking KDE themes!
Without X's network transparency, I'd be upstairs on the linux box half the time, separated from colleagues, and reducing my efficiency.
The only downside -- having to walk upstairs to change CDs occasionally!
However, I also see the need for a slimmer, leaner, meaner X, with a fast (perhaps even kernel-level?) direct rendering system, with less cruft. I have a lowly PIII 550 256Mb at home, and X is a bit of a pig; whereas Win2K's GUI just whizzes along nicely.
I don't necessarily think that network transparency + a fast GUI are mutually exclusive. Surely it's possible to come up with a high-speed rendering and input API that could be controlled remotely via a swappable
I can envisage something like an OpenGL-like pipeline, with a serialised command input, that could be streamed to a specialised hardware accelerated layer on the local machine, or via network to a remote display server? The remote server could afford to be quite minimal in this scenario - a glorified video driver with support for input devices. Surely most of the code necessary for a prototype of this system is already out there?
Don't forget that once you've downloaded and played that Britney MP3, thereby activating the hidden worm, the worm can then go ahead and infect all of your other MP3's, so anyone who downloads ANY of your MP3's would be infected. The worm could then repeat this on the machines of those who download from you... exponential growth. So, theoretically, all you'd need to do is release a single infected Britney MP3, (or better still, a hundred or so of the most popular tracks) and within days you would have infected huge numbers of hosts and MP3 files. Assuming that this type of exploit is possible in the first place, the potential for infestation on P2P networks would be ENORMOUS. But could that amount of activity (file modifications, changing checksums and file sizes, suspicious packets & requests) go unnoticed for any length of time? I'll believe it when I see it.
Danger, Will Robinson! In the UK, there are indeed many lawyers and law firms that advertise "no win, no fee"... But be careful! While it's true that if you lose you don't have to pay your lawyer's fee, you WILL still have to pay your opponent's legal fees, and any damages they win. "no win, no fee" is not some kind of magic insurance against legal costs, as might be implied by certain TV adverts!! (From what I am told, I believe a similar situation exists in the US too, except that such services are advertised more widely and aggressively).
http://www.satirewire.com/news/0010/international. shtml
Why don't they make it illegal to steal mobile phones in the first place? Surely that will stop the criminals! Oh, wait, they already thought of that... :-)
Arrrrrrghghgh!! When are people going to learn that making else something illegal doesn't stop criminals from doing something that's already illegal in the first place? They're CRIMINALS for bob's sake!