A) If people say X is slow, and it turns out not to be XFree86's fault, then the people are wrong. They can say that OpenOffice is slow (it is) or Mozilla is slow (it is) or GTK+ is slow (it is), but saying X is slow is wrong (it's not, as proven by apps that *do* run fast on X). B) Only OS X remembers the contents of windows. Most other OSs do not. So it's not a problem limited to X, and in general it's not a problem that would be a big deal if dumb applications didn't handle EXPOSE events so badly. C) The buffer copy would only make things twice as slow if the *only* thing the server needed to do with each command buffer is copy it to the graphics card. Of course, the actual processing is much more complex than that. In practice, unless you're doing something stupid like drawing single pixels at a time, the overhead imposed by the X protocol is dwarfed by the actual cost of drawing.
Do you have the slightest idea what you're talking about???
A) The Direct Rendering Infrastructure is hardly a hack. It's a design that is optimized to how modern hardware works. B) The DRI is nothing like DirectX 3. DirectX 3 allowed apps to directly touch video memory. Modern graphics cards don't like that. That's why both DRI and new versions of DirectX don't let you get a pointer to video memory. C) The lack of responsiveness in some X apps has little to do with the raw speed of drawing, and more to do with dumb applications and poor schedulers.
That's how I learned to count. So let me get this straight:
1) A period is not necessarily the decimal marker. In French, '.' is the triples marker (100.000 = one hundred thousand), and ',' is the decimal marker.
2) What moron teacher did you have that showed you numbers with more than one decimal point???
Implement a basic set of widgets, including a few of the more important ones you mention (WTF? Audio libraries?), put in a strong system OLE/dynamic linking type thing and leave the rest up to the individual apps. You're confusing two things. The poster I was replying too was bitching about all the dependencies KDE/GNOME apps have. My point was that those dependencies exist because people expect their apps to do a lot of things that people didn't back in the day.
We weren't talking about what functionality needs to be in the server. In truth, none of what I mentioned needs to be in the server (except some small primitives for synchronization of graphics with sound). It can all be done client-side. Putting widgets server-side is dumb for two reasons:
1) Most clients need custom widgets, so you have to implement a low-level immediate-mode API in addition to the widget-oriented API. There is no point in doing that when you can just do the immediate-mode API and be done with it.
2) It restricts evolution. If X had standardized on a toolkit back in the day, it'd still be using Athena, and that would suck royally.
And there aren't 15 different widget libraries that each do the same basic functions.(*COUGH*QTGTKwxWindowsAthenaMotifFLTK*CO UGH*) First of all, nobody uses Athena, Motif, or FLTK apps any more than people use Win 3.1 apps in Windows. Second, wxwindows is a wrapper over GTK+ on Linux. Third, you're obviously not a Windows programmer. Windows programs have several different toolkits. They are, along with the apps that use them:
1) OWL (old Borland apps) 2) VCL (new Borland apps) 3) Win32 (most Windows apps) 4) Office (Microsoft Office) 5).NET 1.x (Visual Studio) 6) Whatever toolkit Visio XP uses. 7) Qt (many apps, including some consumer-level stuff like Adobe PhotoAlbum) 8) Numerous custom toolkits and widget sets (Ephpod, iTunes, QuickTime, Windows Media Player, WinAmp)
That's a lot of toolkits, and four (soon five!) from Microsoft alone! When Longhorn comes out, you can add.NET 2.x to that list.
OS X doesn't work like this today. As for 10.3, OS X does rendering via the CPU into memory buffers. It doesn't use OpenGL for drawing, only compositing.
Anyway, when I say it's moving in this direction, I mean it's already taken some steps, and has some more steps to go. On a modern X setup, pretty much everything *is* client side, including fonts. EVAS and Cairo are fairly mature, and Qt4 and GTK+ 2.8 (which will be built on top of OpenGL and Cairo, respectively), will be out in 1H 2005. At the end of the day, X is comparable to where Windows is now, and when Longhorn comes out, it'll be competitive then too.
Oh, and it's silly for you to criticize me for talking about what is coming, and then mention Longhorn which won't be out for another two years at least.
1) KDE is a *desktop* environment. It's not a windowing system. It is assumed that desktops have soundcards, and applications need to support it. Lot's of apps need sound support. People would bitch if IM clients couldn't beep when you received a message, or if you couldn't have an audio player that integrated neatly into the desktop, etc.
2) There are no games dependencies. The fact that you think so shows that you don't understand what the KDE dependencies really are. Hint: "apt-get install kde" is a meta-package that explicitly installed everything KDE has available. The only required things are "arts," "kdebase" and "kdelibs", and neither of those have any games dependencies.
They aren't part of the windowing system. But they *are* part of the application framework. The original poster wasn't talking about what should be in the windowing system, he was bitching about all the dependencies KDE and GNOME apps have. Try to keep up with the thread, 'k?
I'm definitely not wrong. We're not talking about just putting the graphics driver in the kernel. We're talking about putting the entire window system into the kernel. Window systems are complicated, and it's a definite stability issue, and it shows given that NT 4.0 was far less stable than it's predecessor (NT 3.x). Heck, XP still isn't as stable as NT 3.x.
I don't think you've got a very clear understanding of where the various costs involved are. In the DRI model, the server isn't in the hot-path between application and the GPU. The server manages windows, coodinates access to DRI contexts, provides lot's of utility services and IPC, but doesn't handle graphics data. Graphics data is DMA'ed directly from a userspace buffer to the GPU via a small kernel driver. Putting the server in kernel-space would make creating and removing windows slower, but how fast do those operations need to be? You could make them take no time, and you wouldn't get any speedup in real applications.
How many fucking library dependancies do you need for a modern windowing system? Quite a lot, and they are all pretty necessary. I think you're understimating all the things that modern applications are required to do.
The windowing system should offer basic 2D and 3D functions, widgets (file selection boxes, drop-downs, radio buttons, checkboxes, crap like that), What about ListViews? TreeViews? IconViews? What about internationalized text? Text-layout libraries? Image-loading libraries? Component libraries? HTML renderers? Interprocess-communications libraries? Event-notification libraries? Audio libraries? You can't "un-invent" all of these features. Few people want to go back to the bad-old days of poorly formatted text, apps that can only read BMP files, each app needing to reinvent stuff like PDF display and HTML display widgets, apps that can't talk to each other, apps that can't handle multimedia, apps that don't notice when things in the system change, etc, etc. Doing things "quick, fast, and shitty" is a lot easier than doing things "right," but you'd be stupid to want "shitty" over "right."
They simply used Toolbox calls, and any functions that were needed beyond that were not so hard to include right in the binary itself. What the fuck do you think the toolbox was? It might not have been a shared library (it was a widget in ROM), but it *was* a library nonetheless. It was no different than Qt is, only it can't handle HTML, internationalized text, etc, etc.
Well, the thing about texture data is that you'd have to send it anyway, no matter what you're system looks like. Take the Gimp for example: it keeps the image as a client-side buffer, and just sends the pixel data over the wrire for exposed regions.
In order to get good performance out of such a simple window system, applications need to be reasonably intelligent. One thing I think this entails is getting rid of immediate-mode APIs as the standard way to draw, and make retained-mode APIs the standard way to draw. To refresh your memory:
- An immediate mode API is something like GL or Cairo. The app sends drawing commands, and the engine executes them immediately. If something moves and needs to be redrawn, the app musdo all the work of redrawing the scene.
- A retained-mode API is something like EVAS. Instead of submitting drawing commands, specifies what the scene looks like in a scene graph. The canvas library does all the dirty work of redrawing scenes efficiently when things change.
The plight of X (which has very fast drawing, but often has brain-dead application redraw behavior) shows that no matter how fast your graphics API is, many application programmers (who usually aren't graphics programmers), will still make it look slow by writing apps that redraw the whole scene on even the smallest change. A good canvas API like EVAS fits very well with how most apps work. Canvas APIs are slower when scenes change quickly, but for most apps, most UI elements stay static. Where canvas APIs excel is in allowing simply-coded apps to demostrate good redraw behavior, because all drawing optimization can be done in the canvas.
Of course, for scenes which are animated and quickly-changing, apps should be able to access the underlying immediate-mode API, but this hsould be the exeception rather than the rule.
Oh, btw. The X protocol will probably outlive Xlib. XCB aims to speak the X protocol, while fixing Xlibs shortcomings. So if we had standardized on Xlib, we couldn't have replaced it with XCB today.
The problem is that in any client/server architecture, you're going to need *some* sort of protocol. How else would you do it? And you can't ditch client server, because:
a) History shows that it's rarely the bottleneck (eg: fast GUIs like QNX and BeOS are client/server); b) There is no other good place to put it --- kernel space is too dangerous.
So once you've defined the binary protocol between apps, it's a tiny step to make that network transparent while you're at it.
Where? You mean OpenGL over a network link? It'll probably take more bandwidth than the regular X stream, but mostly because it'll lead to graphically richer apps. In any case, OpenGL was designed for network rendering, and there are very efficient network protocols for GL command streams.
Doubtful. Stripping things out is easy. Writing new stuff that works is hard. X is already moving in the direction Gosling mentioned. Both GTK+ 2.8 and Qt 4 will support rendering via OpenGL. Once you're rendering with OpenGL, you're 90% to wher eGosling is going. At that point, the X-server (actually, the DRI), becomes mostly a manager of window contexts, and doesn't lie at all in the hot-path from application to GPU. Sure, the X servers unused features will take up some space (not too much, though, the X server is only 1.7MB on my system, much smaller than the OpenGL library!) but that's not a huge price to pay for backwards compatibility.
He's not suggesting sending over huge amounts of pixel data. If the app speaks OpenGL, you can ship over the OpenGL command stream. Since OpenGL was designed to support network rendering from day 1, this can be very efficient.
As Gosling mentions, X is moving in this direction today. In a year or two, when the newest X changes are stable, the average GTK+ or Qt app will talk to the server via OpenGL. On most DRI-like setups, the route from GL to GPU looks like:
OpenGL -> userspace command buffer -> graphics memory (DMA via Direct Rendering Manager).
Text layout, fonts, etc, are all done server-side, and the only thing the "server" sees are pixmaps and GL commands.
It's not a matter of sacrificing for the better of the world. It's a matter of competing the best we can, so the entire world can benefit. Economics is no longer the dismal science. Economists accept that when people do they do best, in a free market, everyone benefits. If India can do our programming at a lower cost than we can, we should let them do it, and have our more highly-paid workers do what they do best.
Many Americans have this insane fear certain types of jobs going to third-world countries will lead to a tidal wave that will suck away all our jobs and leave us behind. History shows us that this is not the case. Instead, those jobs go away to make room in our economy for new jobs. We get better jobs, they get better jobs, everyone benefits. Those who are fighting to keep the status quo (like the anonymous poster who replied to you) are working against themselves. The Soviet Union should give us ample illustration of why such an attitude is self-defeating. The soviet central planners tried to enforce the status quo. It worked for awhile, but eventually the rest of the world left them behind, and Soviet workers were stuck doing busy-work that was no longer relevent.
That most things don't have descriptive names, and software is no different. In fact, names in general aren't descriptive. For example, take "Jugalator." If you were a product, what kind of product would you be? I can't tell, a water-carrying-device maybe?
It makes no sense to harp on Sunbird when there are cars running around named Elantra (a made up word!).
Others: Visio PowerPoint Windows Winamp Explo rer (if you think Safari is misnamed) Outlook etc, etc.
The fact of the matter is that product names are marketing tools. They aren't meant to be descriptive, but rather, to evoke pleasing images and thoughts in the minds of the prospective consumer.
1% vs 2-3% is misleading. In absolute numbers, it's a difference of several million people. In terms of relative position, it's the difference between being much smaller than the Mac market and bigger than the Mac market. This last point is important because the size of the Mac market represents a critical mass in getting vendor support.
Slashdot Mirror
A) If people say X is slow, and it turns out not to be XFree86's fault, then the people are wrong. They can say that OpenOffice is slow (it is) or Mozilla is slow (it is) or GTK+ is slow (it is), but saying X is slow is wrong (it's not, as proven by apps that *do* run fast on X).
B) Only OS X remembers the contents of windows. Most other OSs do not. So it's not a problem limited to X, and in general it's not a problem that would be a big deal if dumb applications didn't handle EXPOSE events so badly.
C) The buffer copy would only make things twice as slow if the *only* thing the server needed to do with each command buffer is copy it to the graphics card. Of course, the actual processing is much more complex than that. In practice, unless you're doing something stupid like drawing single pixels at a time, the overhead imposed by the X protocol is dwarfed by the actual cost of drawing.
Do you have the slightest idea what you're talking about???
A) The Direct Rendering Infrastructure is hardly a hack. It's a design that is optimized to how modern hardware works.
B) The DRI is nothing like DirectX 3. DirectX 3 allowed apps to directly touch video memory. Modern graphics cards don't like that. That's why both DRI and new versions of DirectX don't let you get a pointer to video memory.
C) The lack of responsiveness in some X apps has little to do with the raw speed of drawing, and more to do with dumb applications and poor schedulers.
2.4.16
2.4.24
2.4.30
2.4.90
That's how I learned to count. So let me get this straight:
1) A period is not necessarily the decimal marker. In French, '.' is the triples marker (100.000 = one hundred thousand), and ',' is the decimal marker.
2) What moron teacher did you have that showed you numbers with more than one decimal point???
Implement a basic set of widgets, including a few of the more important ones you mention (WTF? Audio libraries?), put in a strong system OLE/dynamic linking type thing and leave the rest up to the individual apps.
O UGH*)
.NET 1.x (Visual Studio)
.NET 2.x to that list.
You're confusing two things. The poster I was replying too was bitching about all the dependencies KDE/GNOME apps have. My point was that those dependencies exist because people expect their apps to do a lot of things that people didn't back in the day.
We weren't talking about what functionality needs to be in the server. In truth, none of what I mentioned needs to be in the server (except some small primitives for synchronization of graphics with sound). It can all be done client-side. Putting widgets server-side is dumb for two reasons:
1) Most clients need custom widgets, so you have to implement a low-level immediate-mode API in addition to the widget-oriented API. There is no point in doing that when you can just do the immediate-mode API and be done with it.
2) It restricts evolution. If X had standardized on a toolkit back in the day, it'd still be using Athena, and that would suck royally.
And there aren't 15 different widget libraries that each do the same basic functions.(*COUGH*QTGTKwxWindowsAthenaMotifFLTK*C
First of all, nobody uses Athena, Motif, or FLTK apps any more than people use Win 3.1 apps in Windows. Second, wxwindows is a wrapper over GTK+ on Linux. Third, you're obviously not a Windows programmer. Windows programs have several different toolkits. They are, along with the apps that use them:
1) OWL (old Borland apps)
2) VCL (new Borland apps)
3) Win32 (most Windows apps)
4) Office (Microsoft Office)
5)
6) Whatever toolkit Visio XP uses.
7) Qt (many apps, including some consumer-level stuff like Adobe PhotoAlbum)
8) Numerous custom toolkits and widget sets (Ephpod, iTunes, QuickTime, Windows Media Player, WinAmp)
That's a lot of toolkits, and four (soon five!) from Microsoft alone! When Longhorn comes out, you can add
OS X doesn't work like this today. As for 10.3, OS X does rendering via the CPU into memory buffers. It doesn't use OpenGL for drawing, only compositing.
Anyway, when I say it's moving in this direction, I mean it's already taken some steps, and has some more steps to go. On a modern X setup, pretty much everything *is* client side, including fonts. EVAS and Cairo are fairly mature, and Qt4 and GTK+ 2.8 (which will be built on top of OpenGL and Cairo, respectively), will be out in 1H 2005. At the end of the day, X is comparable to where Windows is now, and when Longhorn comes out, it'll be competitive then too.
Oh, and it's silly for you to criticize me for talking about what is coming, and then mention Longhorn which won't be out for another two years at least.
1) KDE is a *desktop* environment. It's not a windowing system. It is assumed that desktops have soundcards, and applications need to support it. Lot's of apps need sound support. People would bitch if IM clients couldn't beep when you received a message, or if you couldn't have an audio player that integrated neatly into the desktop, etc.
2) There are no games dependencies. The fact that you think so shows that you don't understand what the KDE dependencies really are. Hint: "apt-get install kde" is a meta-package that explicitly installed everything KDE has available. The only required things are "arts," "kdebase" and "kdelibs", and neither of those have any games dependencies.
They aren't part of the windowing system. But they *are* part of the application framework. The original poster wasn't talking about what should be in the windowing system, he was bitching about all the dependencies KDE and GNOME apps have. Try to keep up with the thread, 'k?
I'm definitely not wrong. We're not talking about just putting the graphics driver in the kernel. We're talking about putting the entire window system into the kernel. Window systems are complicated, and it's a definite stability issue, and it shows given that NT 4.0 was far less stable than it's predecessor (NT 3.x). Heck, XP still isn't as stable as NT 3.x.
I don't think you've got a very clear understanding of where the various costs involved are. In the DRI model, the server isn't in the hot-path between application and the GPU. The server manages windows, coodinates access to DRI contexts, provides lot's of utility services and IPC, but doesn't handle graphics data. Graphics data is DMA'ed directly from a userspace buffer to the GPU via a small kernel driver. Putting the server in kernel-space would make creating and removing windows slower, but how fast do those operations need to be? You could make them take no time, and you wouldn't get any speedup in real applications.
How many fucking library dependancies do you need for a modern windowing system?
Quite a lot, and they are all pretty necessary.
I think you're understimating all the things that modern applications are required to do.
The windowing system should offer basic 2D and 3D functions, widgets (file selection boxes, drop-downs, radio buttons, checkboxes, crap like that),
What about ListViews? TreeViews? IconViews? What about internationalized text? Text-layout libraries? Image-loading libraries? Component libraries? HTML renderers? Interprocess-communications libraries? Event-notification libraries? Audio libraries? You can't "un-invent" all of these features. Few people want to go back to the bad-old days of poorly formatted text, apps that can only read BMP files, each app needing to reinvent stuff like PDF display and HTML display widgets, apps that can't talk to each other, apps that can't handle multimedia, apps that don't notice when things in the system change, etc, etc. Doing things "quick, fast, and shitty" is a lot easier than doing things "right," but you'd be stupid to want "shitty" over "right."
They simply used Toolbox calls, and any functions that were needed beyond that were not so hard to include right in the binary itself.
What the fuck do you think the toolbox was? It might not have been a shared library (it was a widget in ROM), but it *was* a library nonetheless. It was no different than Qt is, only it can't handle HTML, internationalized text, etc, etc.
Well, the thing about texture data is that you'd have to send it anyway, no matter what you're system looks like. Take the Gimp for example: it keeps the image as a client-side buffer, and just sends the pixel data over the wrire for exposed regions.
In order to get good performance out of such a simple window system, applications need to be reasonably intelligent. One thing I think this entails is getting rid of immediate-mode APIs as the standard way to draw, and make retained-mode APIs the standard way to draw. To refresh your memory:
- An immediate mode API is something like GL or Cairo. The app sends drawing commands, and the engine executes them immediately. If something moves and needs to be redrawn, the app musdo all the work of redrawing the scene.
- A retained-mode API is something like EVAS. Instead of submitting drawing commands, specifies what the scene looks like in a scene graph. The canvas library does all the dirty work of redrawing scenes efficiently when things change.
The plight of X (which has very fast drawing, but often has brain-dead application redraw behavior) shows that no matter how fast your graphics API is, many application programmers (who usually aren't graphics programmers), will still make it look slow by writing apps that redraw the whole scene on even the smallest change. A good canvas API like EVAS fits very well with how most apps work. Canvas APIs are slower when scenes change quickly, but for most apps, most UI elements stay static. Where canvas APIs excel is in allowing simply-coded apps to demostrate good redraw behavior, because all drawing optimization can be done in the canvas.
Of course, for scenes which are animated and quickly-changing, apps should be able to access the underlying immediate-mode API, but this hsould be the exeception rather than the rule.
Oh, btw. The X protocol will probably outlive Xlib. XCB aims to speak the X protocol, while fixing Xlibs shortcomings. So if we had standardized on Xlib, we couldn't have replaced it with XCB today.
The problem is that in any client/server architecture, you're going to need *some* sort of protocol. How else would you do it? And you can't ditch client server, because:
a) History shows that it's rarely the bottleneck (eg: fast GUIs like QNX and BeOS are client/server);
b) There is no other good place to put it --- kernel space is too dangerous.
So once you've defined the binary protocol between apps, it's a tiny step to make that network transparent while you're at it.
Bah, I'm a moron. He *does* apparently suggest sending pixel streams. Why would he do that??? OpenGL works just fine over a network!
Where? You mean OpenGL over a network link? It'll probably take more bandwidth than the regular X stream, but mostly because it'll lead to graphically richer apps. In any case, OpenGL was designed for network rendering, and there are very efficient network protocols for GL command streams.
Doubtful. Stripping things out is easy. Writing new stuff that works is hard. X is already moving in the direction Gosling mentioned. Both GTK+ 2.8 and Qt 4 will support rendering via OpenGL. Once you're rendering with OpenGL, you're 90% to wher eGosling is going. At that point, the X-server (actually, the DRI), becomes mostly a manager of window contexts, and doesn't lie at all in the hot-path from application to GPU. Sure, the X servers unused features will take up some space (not too much, though, the X server is only 1.7MB on my system, much smaller than the OpenGL library!) but that's not a huge price to pay for backwards compatibility.
If you're just drawing pixels at a time, you're screwed anyway. In any case, they were shipping WBXML (binary-XML) not XML.
He's not suggesting sending over huge amounts of pixel data. If the app speaks OpenGL, you can ship over the OpenGL command stream. Since OpenGL was designed to support network rendering from day 1, this can be very efficient.
As Gosling mentions, X is moving in this direction today. In a year or two, when the newest X changes are stable, the average GTK+ or Qt app will talk to the server via OpenGL. On most DRI-like setups, the route from GL to GPU looks like:
OpenGL -> userspace command buffer -> graphics memory (DMA via Direct Rendering Manager).
Text layout, fonts, etc, are all done server-side, and the only thing the "server" sees are pixmaps and GL commands.
It's not a matter of sacrificing for the better of the world. It's a matter of competing the best we can, so the entire world can benefit. Economics is no longer the dismal science. Economists accept that when people do they do best, in a free market, everyone benefits. If India can do our programming at a lower cost than we can, we should let them do it, and have our more highly-paid workers do what they do best.
Many Americans have this insane fear certain types of jobs going to third-world countries will lead to a tidal wave that will suck away all our jobs and leave us behind. History shows us that this is not the case. Instead, those jobs go away to make room in our economy for new jobs. We get better jobs, they get better jobs, everyone benefits. Those who are fighting to keep the status quo (like the anonymous poster who replied to you) are working against themselves. The Soviet Union should give us ample illustration of why such an attitude is self-defeating. The soviet central planners tried to enforce the status quo. It worked for awhile, but eventually the rest of the world left them behind, and Soviet workers were stuck doing busy-work that was no longer relevent.
This is awful! Now, these newly uplifted Indian masses will take even more of our programming jobs!
Grumble, grumble...populism...communism...grumble grumble!
That most things don't have descriptive names, and software is no different. In fact, names in general aren't descriptive. For example, take "Jugalator." If you were a product, what kind of product would you be? I can't tell, a water-carrying-device maybe?
It makes no sense to harp on Sunbird when there are cars running around named Elantra (a made up word!).
Others:o rer (if you think Safari is misnamed)
Visio
PowerPoint
Windows
Winamp
Expl
Outlook
etc, etc.
The fact of the matter is that product names are marketing tools. They aren't meant to be descriptive, but rather, to evoke pleasing images and thoughts in the minds of the prospective consumer.
1% vs 2-3% is misleading. In absolute numbers, it's a difference of several million people. In terms of relative position, it's the difference between being much smaller than the Mac market and bigger than the Mac market. This last point is important because the size of the Mac market represents a critical mass in getting vendor support.
Two words: Visual FoxPro.
At least Firefox makes sense in a sci-fi fantasy sort of way. But Fox*Pro*?