I don't give a shit about the projects. Then why are you responding to post about a *NIX desktop project?
The same developers work on both No, they are not.
and they're all the better part of a decade behind everyone else. Apple is a few years ahead on transparency, but it doesn't look like they'll maintain that lead when it comes to GPU-accelerated desktops. Microsoft isn't any further along than X --- indeed, with X.org 6.8, X will be significantly ahead of Microsoft, which won't have a composited desktop until Longhorn comes out in 2007.
The simple fact of the matter is that *no-one* is innovating. No, not even Longhorn is innovative in the slightest. We're at a period in the computing industry where we're just rehashing ideas from the 1980's. There is no point in getting self-righteous over who rehashed a 20-year-old idea first.
Well, that's just a silly thing to say. Who is the competition? Microsoft? Well, Windows XP and X got anti-aliased fonts at about the same time, so there isn't really anything they have that X doesn't.
Yes, Apple was quite a bit ahead on the "true transparency" thing, but I don't think the technique is generally useful without hardware acceleration of compositing, which was released just 2 years ago. Beyond that, both are just an incremental step to a true GPU accelerated desktop, and X.org is as far in that respect as Apple or Microsoft. Nobody has a fully GPU accelerated desktop yet (no, Quartz "Extreme" is not what you think it is) right now, but all three have things in progress.
Sorry to break it to you, but Quartz Extreme doesn't allow the CPU to do all the hard work (and doesn't really use the T&L engine anyway). Rendering is still done via the CPU --- OpenGL is used only at the very last step, where the transparent windows are composited together. If you've got Render acceleration in X.org 6.8, then you've got 99% of what MacOS X has.
This will change in OS X 10.4, or so I've heard, which will, like Longhorn and Cairo, use the GPU for 2D rendering acceleration.
It tends to be more of a configuration issue than anything else. On my setup (Freetype 2.1.9 without bytecode interpreter, Albany AMT main font, and 133 dpi LCD) the fonts look absolutely great. Unfortunately, most distros don't package such nice fonts out of box.
2) Why would window managers have direct access to video memory? You toolkits, right?
3) Modern graphics cards don't like apps directly accessing their memory. That's why Microsoft took it out of Direct3D 8.x (not so direct anymore, is it!) and why OpenGL has designed from day 1 for client/server operation.
4) X doesn't use a network layer, it uses an IPC layer. Sockets are very fast, and some of the fastest UIss (BeOS's, QNX's), used some form of client/server with IPC.
Eh? These screenshots aren't from a release product you moron. X doesn't *have* any release icons. These screenshots are just from some guy running a theme that uses Apple's icon-set, just like you can get Windows themes that use the KDE Crystal icon set.
Not all information is equally relevent. Making further objects (determined by stacking order) less noticible would help the user concentrate on foreground objects.
Just don't run xcompmgr. Your comment would be more scathing if they hadn't already taken your viewpoint into account and made it so easy to turn off the feature!
Well, older computers probably will just disable the composite manager --- the overhead doesn't come into play until that is started.
There are quite a few legtimate reasons to do transparency:
1) It looks much nicer. In particular, non-square window edges can be nicely alpha-blended with the background, instead of standing out as they do now. Compositing allows for fully flicker-free redraw and resize, so you never have to bear ugly partially-drawn windows.
2) Transparent windows have their uses to allow increased information density. For example, sometimes when editing a photo, I quickly want to see or edit something underneath my toolbar, without moving it away then moving it back. A partially transparent toolbar could do just the trick.
3) It lays the ground-work for more advanced features, like an OpenGL-accelerated X server.
You're kinda missing the point. The essential technology in Composite is the ability to rediriect window hierarchies arbitrary targets. The composition manager can then do with these windows whatever it want's, without affecting the underlying technology. This is quite a step forward from what Apple has, where the composition mechanism is tied with the composition policy.
The current xcompmgr program is just a demo --- who cares what the drop-shadows look like? It can and will be replaced as window managers subsume the composite manager functionality.
The biggest problems with multithreading came from apps (like Mozilla) that were designed for single-threading. The Be API was also part of the problem, because it didn't force a seperation fo model and view, which would have made it easier to put each in it's own thread. It's interesting to note that Longhorn will run each Avalon window in it's own thread, since Avalon has a much better seperation of model and view.
Well, the complexity of multithreading depends very heavily on your synchronization model. The "locks around shared resources" model is a great deal more complicated than the message-passing model. The message-passing model tends to be avoided, because it has inherently more overhead, but with multicore hyperthreaded processors becoming more common,, it might be the case that the overhead of message-passing is outweighed by it's ability to let the code utilize the extra processors.
If you consider that kernels are inherently multithreaded (each process shares the kernel memory space), you can see a good illustration of this. FreeBSD and Linux have very complex fine-grained locking models, while Dragonfly BSD is trying to move to a much simpler message-passing model.
Also, X compositing will remedy one problem of non-multithreaded apps (specifically, expose lag), but won't fix other problems. For example, it'll do nothing to fix an app that blocks display updates and input processing for long periods of time while doing I/O and computation. So the user will be able to see the window (well, as long as it's not resized), but not be able to interact with it.
Well, Con Kolivas has his staircase scheduler patch that's trying to get better interactivity, and recently Nick Piggen also has a scheduler patch designed to get better interactivity. See these kerneltrap.org stories:
Don't be a moron. I never said that the BeOS scheduler was all-around better than the O(1) scheduler. I pointed out that the O(1) scheduler is *way* more scalable. However, the O(1) scheduler also has problems with interactivity estimation --- ie: figuring out what apps are interactive, and thus should get faster response times. That interactivity estimation is what made the BeOS so good for desktop workloads.
Do you prefer not to see a menu at all for a second? I'd find that even more anoying. I'd prefer it if the app loaded it's icons when it loaded. A 32bpp 16x16 icon takes up 1kb of memory. The average app has maybe a couple of dozen menu icons. Epiphany, for example, has 33. That's a trivial memory overhead.
It has become a lot better. But I agree it is still noticable. It's still not nearly good enough. With the XSYNC patches, Qt/KDE is at the "transparent" point on my system, where I can't notice any lag except on the most complex windows (Konqueror browsing the QApplication documentation, for example). Yet, even the GNOME help viewer can't resize without lag. Gedit with a large (thousands of lines) file loaded is slow enough to be nearly unusable.
I don't use Epiphany so I've never seen what you mean. But most major GNOME apps are multithreaded. You'll see the same problem in Firefox too. If a website takes a long time to respond, or a page takes a long time to render, the UI will lock up in the meantime. Most GNOME and KDE apps do not run the UI in a seperate threat. For example, start up Epiphany and go to "Edit->Preferences." The menu will dissapear, and for about a second, the toolbar underneath won't redraw because the thread is busy loading the dialog.
Gah, it's probably your video card and/or your settings more than anything else (make sure GDK_USE_XFT is defined in your environment). It's not my video card or settings. It's been the same on every Linux distro I've ever used, and I've used a lot of htem.
nVidia is the only way to go on Linux. Sorry but everything just works so much better with nVidia. I've got a GeForce4Go running the NVIDIA drivers.
GNOME starts up hella faster than KDE. Who cares how long it takes to start up?
It feels a lot better, Arguably, yes it does, but not in terms of performance and responsiveness.
the fonts look better, The fonts are identical. Both render Freetype via Xft. KDE doesn't have a GUI yet for controlling the Xft.hinstyle setting, however, like GNOME does, but you can put it in your.Xresources file manually.
Nautilus is tons better than Konq also. At first Nautilus sucked but it has gotten really good lately. Nautilus still can't, as of 2.6.2, browse a fraction of the protocols Konqueror can handle. That alone makes it useless to me.
You probably do, it's just that you're so used to it that you accept it as being normal. I've got a 2.0GHz P4. Using GNOME for me is very hard, because it feels "heavy." The heavy feeling comes from three major places:
1) Menus are displayed before icons are loaded, so the first time you use a menu, all the icons get loaded from disk, and you have a blank menu for about a second until the loading is done.
2) Window redraw and resize is handled poorly. Even the simplest GNOME apps (eg: Gedit), can't resize smoothly without the content area lagging behind the window frame. Moving or resizing a window above another window causes all sorts of ugly effects as the toolkit takes it's sweet time handling the expose events.
3) The lack of multithreading causes the UI of apps like Epiphany to lock for several seconds when loading/rendering complex pages. This is a major no-no. I don't care if the app is simulating the universe --- the GUI should always respond immediately to the user.
Yes, most of these things are cosmetic, but cosmetic things can have deep psychological impacts. The redraw problems, in particular, make it seem like the computer is having trouble keeping up with my workflow, and destroys the otherwise solid feel of the GNOME desktop. The lack of a solid feel, in turn, makes the desktop irritating and tiresome to use in the long-run.
PS> You're "if I wanted speed I wouldn't even install X" comment is bogus. I like lynx a lot, but I'd rather surf Slashdot with a graphical browser, thank you very much.
Well, the first thing to remember is that good technology doesn't ensure success. Indeed, the general rule is that the first product to be "good enough" is the winner, not the "best" product.
Now, there are a couple of reasons why BeOS was so great:
1) It was pervasively multithreaded. Each window had it's own rendering thread that ran independently of the application logic. This allowed apps to be very responsive, even under heavy load. It's sad that even on my 2.0GHz P4, Mozilla still blocks the UI for several seconds when certain pages take too long to load or render.
2) It had a phenomenal scheduler. It wasn't comparable, in many ways, to Linux's O(1) scheduler (it wasn't very scalable), but it was wonderfully optimized for interactive use. It's interactivity estimation was lightyears ahead of what's in the O(1) scheduler now.
3) It's multimedia subsystem was very good at moving data around the system efficiently.
4) It's toolkit was well-coded with respect to smart redraw and resize behavior.
Interestingly, the OS wasn't all that structurally different from Linux. It had a fairly POSIX-complient modular kernel. It run it's video and audio subsystems as a seperate process (like X, aRts, and Jack). It was just very well-implemented with an eye towards a fast and elegant UI.
Of course, the OS had it's darksides. The toolkit wasn't font-sensitive and layout-based, the VM was antiquated, I/O and network performance was only decent, etc. However, for the average desktop, this really wasn't a big deal, and not something that couldn't have been fixed had BeOS survived to today.
Slashdot Mirror
I don't give a shit about the projects.
Then why are you responding to post about a *NIX desktop project?
The same developers work on both
No, they are not.
and they're all the better part of a decade behind everyone else.
Apple is a few years ahead on transparency, but it doesn't look like they'll maintain that lead when it comes to GPU-accelerated desktops. Microsoft isn't any further along than X --- indeed, with X.org 6.8, X will be significantly ahead of Microsoft, which won't have a composited desktop until Longhorn comes out in 2007.
The simple fact of the matter is that *no-one* is innovating. No, not even Longhorn is innovative in the slightest. We're at a period in the computing industry where we're just rehashing ideas from the 1980's. There is no point in getting self-righteous over who rehashed a 20-year-old idea first.
Well, that's just a silly thing to say. Who is the competition? Microsoft? Well, Windows XP and X got anti-aliased fonts at about the same time, so there isn't really anything they have that X doesn't.
Yes, Apple was quite a bit ahead on the "true transparency" thing, but I don't think the technique is generally useful without hardware acceleration of compositing, which was released just 2 years ago. Beyond that, both are just an incremental step to a true GPU accelerated desktop, and X.org is as far in that respect as Apple or Microsoft. Nobody has a fully GPU accelerated desktop yet (no, Quartz "Extreme" is not what you think it is) right now, but all three have things in progress.
Sorry to break it to you, but Quartz Extreme doesn't allow the CPU to do all the hard work (and doesn't really use the T&L engine anyway). Rendering is still done via the CPU --- OpenGL is used only at the very last step, where the transparent windows are composited together. If you've got Render acceleration in X.org 6.8, then you've got 99% of what MacOS X has.
This will change in OS X 10.4, or so I've heard, which will, like Longhorn and Cairo, use the GPU for 2D rendering acceleration.
It tends to be more of a configuration issue than anything else. On my setup (Freetype 2.1.9 without bytecode interpreter, Albany AMT main font, and 133 dpi LCD) the fonts look absolutely great. Unfortunately, most distros don't package such nice fonts out of box.
1) No, it's not. There are lot's of slower ones.
2) Why would window managers have direct access to video memory? You toolkits, right?
3) Modern graphics cards don't like apps directly accessing their memory. That's why Microsoft took it out of Direct3D 8.x (not so direct anymore, is it!) and why OpenGL has designed from day 1 for client/server operation.
4) X doesn't use a network layer, it uses an IPC layer. Sockets are very fast, and some of the fastest UIss (BeOS's, QNX's), used some form of client/server with IPC.
Eh? These screenshots aren't from a release product you moron. X doesn't *have* any release icons. These screenshots are just from some guy running a theme that uses Apple's icon-set, just like you can get Windows themes that use the KDE Crystal icon set.
Not all information is equally relevent. Making further objects (determined by stacking order) less noticible would help the user concentrate on foreground objects.
kdrive KeithP's hacking branch, apparently. The extensions used to achieve the functionality in the screenshots were integrated into X.org
Just don't run xcompmgr. Your comment would be more scathing if they hadn't already taken your viewpoint into account and made it so easy to turn off the feature!
Well, older computers probably will just disable the composite manager --- the overhead doesn't come into play until that is started.
There are quite a few legtimate reasons to do transparency:
1) It looks much nicer. In particular, non-square window edges can be nicely alpha-blended with the background, instead of standing out as they do now. Compositing allows for fully flicker-free redraw and resize, so you never have to bear ugly partially-drawn windows.
2) Transparent windows have their uses to allow increased information density. For example, sometimes when editing a photo, I quickly want to see or edit something underneath my toolbar, without moving it away then moving it back. A partially transparent toolbar could do just the trick.
3) It lays the ground-work for more advanced features, like an OpenGL-accelerated X server.
You're kinda missing the point. The essential technology in Composite is the ability to rediriect window hierarchies arbitrary targets. The composition manager can then do with these windows whatever it want's, without affecting the underlying technology. This is quite a step forward from what Apple has, where the composition mechanism is tied with the composition policy.
The current xcompmgr program is just a demo --- who cares what the drop-shadows look like? It can and will be replaced as window managers subsume the composite manager functionality.
- X.org should be in the next Debian X-strike force update, although I don't know how long that'd take.
- The eventual goal is to implement the X server on top of OpenGL, so transparency and 2D operations can be hardware accelerated.
Welcome to capitalism. Take the heat or get out of the fire.
Don't forget iPhoto, iTunes, iMovie, iLife, iCal, iDisk, iTheListIsEndless.
KDE4 will probably not use Cairo. Qt has it's own painter API with OpenGL backend.
The biggest problems with multithreading came from apps (like Mozilla) that were designed for single-threading. The Be API was also part of the problem, because it didn't force a seperation fo model and view, which would have made it easier to put each in it's own thread. It's interesting to note that Longhorn will run each Avalon window in it's own thread, since Avalon has a much better seperation of model and view.
Well, the complexity of multithreading depends very heavily on your synchronization model. The "locks around shared resources" model is a great deal more complicated than the message-passing model. The message-passing model tends to be avoided, because it has inherently more overhead, but with multicore hyperthreaded processors becoming more common,, it might be the case that the overhead of message-passing is outweighed by it's ability to let the code utilize the extra processors.
If you consider that kernels are inherently multithreaded (each process shares the kernel memory space), you can see a good illustration of this. FreeBSD and Linux have very complex fine-grained locking models, while Dragonfly BSD is trying to move to a much simpler message-passing model.
Also, X compositing will remedy one problem of non-multithreaded apps (specifically, expose lag), but won't fix other problems. For example, it'll do nothing to fix an app that blocks display updates and input processing for long periods of time while doing I/O and computation. So the user will be able to see the window (well, as long as it's not resized), but not be able to interact with it.
Well, Con Kolivas has his staircase scheduler patch that's trying to get better interactivity, and recently Nick Piggen also has a scheduler patch designed to get better interactivity. See these kerneltrap.org stories:
Nick Piggen's scheduler patch
Con Kolivas's scheduler patch
Don't be a moron. I never said that the BeOS scheduler was all-around better than the O(1) scheduler. I pointed out that the O(1) scheduler is *way* more scalable. However, the O(1) scheduler also has problems with interactivity estimation --- ie: figuring out what apps are interactive, and thus should get faster response times. That interactivity estimation is what made the BeOS so good for desktop workloads.
There is a reason why Andrew Morton is experimenting with different CPU schedulers in his -mm tree.
Do you prefer not to see a menu at all for a second? I'd find that even more anoying.
I'd prefer it if the app loaded it's icons when it loaded. A 32bpp 16x16 icon takes up 1kb of memory. The average app has maybe a couple of dozen menu icons. Epiphany, for example, has 33. That's a trivial memory overhead.
It has become a lot better. But I agree it is still noticable.
It's still not nearly good enough. With the XSYNC patches, Qt/KDE is at the "transparent" point on my system, where I can't notice any lag except on the most complex windows (Konqueror browsing the QApplication documentation, for example). Yet, even the GNOME help viewer can't resize without lag. Gedit with a large (thousands of lines) file loaded is slow enough to be nearly unusable.
I don't use Epiphany so I've never seen what you mean. But most major GNOME apps are multithreaded.
You'll see the same problem in Firefox too. If a website takes a long time to respond, or a page takes a long time to render, the UI will lock up in the meantime. Most GNOME and KDE apps do not run the UI in a seperate threat. For example, start up Epiphany and go to "Edit->Preferences." The menu will dissapear, and for about a second, the toolbar underneath won't redraw because the thread is busy loading the dialog.
Gah, it's probably your video card and/or your settings more than anything else (make sure GDK_USE_XFT is defined in your environment).
.Xresources file manually.
It's not my video card or settings. It's been the same on every Linux distro I've ever used, and I've used a lot of htem.
nVidia is the only way to go on Linux. Sorry but everything just works so much better with nVidia.
I've got a GeForce4Go running the NVIDIA drivers.
GNOME starts up hella faster than KDE.
Who cares how long it takes to start up?
It feels a lot better,
Arguably, yes it does, but not in terms of performance and responsiveness.
the fonts look better,
The fonts are identical. Both render Freetype via Xft. KDE doesn't have a GUI yet for controlling the Xft.hinstyle setting, however, like GNOME does, but you can put it in your
Nautilus is tons better than Konq also. At first Nautilus sucked but it has gotten really good lately.
Nautilus still can't, as of 2.6.2, browse a fraction of the protocols Konqueror can handle. That alone makes it useless to me.
It does happen in XFCE. It does for me, anyway.
You probably do, it's just that you're so used to it that you accept it as being normal. I've got a 2.0GHz P4. Using GNOME for me is very hard, because it feels "heavy." The heavy feeling comes from three major places:
1) Menus are displayed before icons are loaded, so the first time you use a menu, all the icons get loaded from disk, and you have a blank menu for about a second until the loading is done.
2) Window redraw and resize is handled poorly. Even the simplest GNOME apps (eg: Gedit), can't resize smoothly without the content area lagging behind the window frame. Moving or resizing a window above another window causes all sorts of ugly effects as the toolkit takes it's sweet time handling the expose events.
3) The lack of multithreading causes the UI of apps like Epiphany to lock for several seconds when loading/rendering complex pages. This is a major no-no. I don't care if the app is simulating the universe --- the GUI should always respond immediately to the user.
Yes, most of these things are cosmetic, but cosmetic things can have deep psychological impacts. The redraw problems, in particular, make it seem like the computer is having trouble keeping up with my workflow, and destroys the otherwise solid feel of the GNOME desktop. The lack of a solid feel, in turn, makes the desktop irritating and tiresome to use in the long-run.
PS> You're "if I wanted speed I wouldn't even install X" comment is bogus. I like lynx a lot, but I'd rather surf Slashdot with a graphical browser, thank you very much.
Well, the first thing to remember is that good technology doesn't ensure success. Indeed, the general rule is that the first product to be "good enough" is the winner, not the "best" product.
Now, there are a couple of reasons why BeOS was so great:
1) It was pervasively multithreaded. Each window had it's own rendering thread that ran independently of the application logic. This allowed apps to be very responsive, even under heavy load. It's sad that even on my 2.0GHz P4, Mozilla still blocks the UI for several seconds when certain pages take too long to load or render.
2) It had a phenomenal scheduler. It wasn't comparable, in many ways, to Linux's O(1) scheduler (it wasn't very scalable), but it was wonderfully optimized for interactive use. It's interactivity estimation was lightyears ahead of what's in the O(1) scheduler now.
3) It's multimedia subsystem was very good at moving data around the system efficiently.
4) It's toolkit was well-coded with respect to smart redraw and resize behavior.
Interestingly, the OS wasn't all that structurally different from Linux. It had a fairly POSIX-complient modular kernel. It run it's video and audio subsystems as a seperate process (like X, aRts, and Jack). It was just very well-implemented with an eye towards a fast and elegant UI.
Of course, the OS had it's darksides. The toolkit wasn't font-sensitive and layout-based, the VM was antiquated, I/O and network performance was only decent, etc. However, for the average desktop, this really wasn't a big deal, and not something that couldn't have been fixed had BeOS survived to today.