And what exactly about that is ahead of Mac OS X, as it stands now? I certainly know that 1 and 2 have been there since 10.0, and 3 was added in 10.2. ---------- Quartz "Extreme" accelerates only window compositing. Drawing (ie. everything else) is still done via the CPU. That means if you actually use lots of vector graphics, it'll run dog-slow. Why do you think OS X's UI is still mostly composed of bitmaps? Both FD.O and Longhorn will use OpenGL to accelerate actual drawing, so you can have very rich vector applications without a performance hit. Read Apple's 2002 SIGGRAPH paper for how Quartz "Extreme" works.
like anti-aliasing are completely sorted out, once and for all. ------- Anti-aliasing has worked for years. What version of KDE/GNOME are you using?
Freedesktop.org is working to put this in. They already have a fully-compositing X that you can download right now. Window movement is pretty good (especially impressive given that its unaccelerated!), but resize is really slow because of very unoptimized code. When it gets its new acceleration architecture, everything should be a lot faster.
Actually, Quartz does not draw line by line. Quartz preserves a bitmap of each window, and when something damages the contents of the window, restores the image from that bitmap. This takes up tons of memory (need window buffers even if window is hidden) but eliminates any streaking.
And resizes on OS X are really slow, though that doesn't have a lot to do with the double-buffered approach. Quartz is just really slow overall.
Anyway, I use OS X 10.2.8 on an 800MHz G4 17" iMac, and it definitely suffers from choppy resize operation.
Fluxbox, Konqueror opened to Google News: Streaking. Fluxbox, Konqueror opened to kdelook: Streaking.
Metacity, Konqueror opened to Google News: No steaking. Metacity, Konqueror opened to kdelook: Streaking.
Kwin, Konqueror opened to Google News: No streaking. Kwin, Konqueror opened to kdelook: No streaking.
In particular, kdelook is the only site complex enough to notice streaking with kwin.
Configuration: 2.0 GHz Pentium 4 on an Inspiron 8200 GeForce 4 Go 440 w/ 64MB of RAM NVIDIA binary drivers, 5336 (RenderAccel on) 1600x1200 15" LCD 640MB RAM XFree86 4.3.0 Debian sid KDE CVS
Note: I've got kwin patches that are not in KDE 3.2. If you want to replicate the test, either compile the latest CVS, or use KDE 3.1.x. KDE 3.2's kwin is a new one, and was not highly optimized relative to previous kwin's.
It would be *really* hard to write a compatibility layer for XFree drivers. I looked into doing that myself awhile ago, and while it would be possible, it would involve implementing many XFree86 DDX calls in kdrive. The NVIDIA driver, for example, makes 400 different calls into XFree86. If something like that were to be done, it'd be a long term project. Most importantly, there is no mention of this in the mailing lists.
Maybe what you're thinking is that they plan to release XFree86 with the FD.O Xlibs, which would be doable. It would only include compositing, though, in the sense of supporting the Composite extension, not full window compositing.
Okay, test performed on Linux 2.6.1, XFree86 4.3.0 (NVIDIA binary drivers), with KDE CVS and Galeon. Machine is a P4 2.0 GHz.
To perform this test, start with a good web browser (firefox, mozilla, konqueror, galeon, whatever). Enable the equivalent of "Opaque Window Moving" on your window manager. Open a browser window and drag it to the bottom-left corner. Now drag it back. What happens? -------- The window moves?
Open two windows. Drag one across the other. What happens? --------- The window moves again?
What happens is smearing. --------- Except it doesn't?
Gross. Ugly. Unacceptable. ------- It would be, if it happened:)
The problems you mention are not the fault of X. Its the fault of the applications. Your test *does* show some trailing in Mozilla. But KDE doesn't exhibit these problems, mainly because Qt rocks.
Linking against libraries is a derivative work. Otherwise, copyright would be trivial to defeat. Just take the code you want to use and put it in its own shared library, and voila, no copyright issues!
Its hardly charity. The pro graphics workstation market likes the price/performance of Intel + NVIDIA + Linux. SGI's x86 machines all run NVIDIA. They make a nice bit of change from their Linux drivers. That's why their Linux drivers aren't half-assed like ATI's.
Actually, NVIDIA, anyway, seems reasonably supportive of the efforts. The radical redesign of the driver API is necessary because they want to seperate the OpenGL drivers from the X server, so the X server can do its drawing through OpenGL.
There's tons of BSD licensed code in Linux. But its all the new-style BSD license. The new XFree license is like the old BSD license, with the advertising clause.
Stuff is racing forward at freedesktop.org. They are planning (and already have a lot of code for):
- A fully double-buffered window system - Vector graphics library (Cairo) - Fully accelerated drawing via OpenGL - X-independent OpenGL subsystem
Those features would put X ahead of MacOS X (as it is now) and on a par with Longhorn. And they've made real progress so far --- you can download the FD.O X server today and see the first two features in action.
Let's phrase it accurately. Its not that QE doesn't offer "a complete hardware acceleration scheme." Its more appropriate to say that QE accelerates only a small portion of the graphics system.
My big beef is that people do not phrase it that way! I've heard literally dozens of Mac fanatics spout of about how Quartz "Extreme" offers a fully hardware accelerated GUI! What sickens me is that the Apple fans distort the perception of Quartz "Extreme" even beyond the lofty exaggerations of Apple's marketing department!
I'm not bitching about Quartz "Extreme" as a technology. I think its fine for what it does. I think hardware-accelerating compositing is kinda stupid without accelerating drawing, but hey, Apple's market responds to gimmicks like transparent windows. It just pisses me off that people blow it completely out of perspective.
Don't forget panels and menus. KDE's panels and menus are a lot more customizable. For example, there is no way to put the GNOME menu at the top, and GNOME panels just have the standard-autohide, instead of the "allow windows to overlap panel" option KDE has. The latter is, imho, a perfect compromise between saving screen space and having quick access, because although the panel can be overlapped, it rises to the top when you move your mouse to the window edge. However, unlike with autohide, the panel is usually visible because windows usually aren't overlapping it.
Both KDE and GNOME have repeatedly stated that they are willing to compromise. freedesktop.org is a manifestation of that willingness to compromise. However, what neither group is willing to do is to start over. Throwing out GTK+ or Qt would mean rewriting *everything* in the desktop, and that's just not a practical thing to do.
Slashdot Mirror
A conservative against free trade? Oh, the hipocrisy rans rampant!
We believe in less government power... except when it comes to deciding who you can fuck.
We believe in less government power... except when it comes to deciding what you can research.
We believe in less government power... except when it comes to deciding who you can hire.
You don't have to be "sought out by an Indian company." You merely need a job offer for one. Nothing prevents you from seeking those jobs yourself.
As far as I'm concerned, that's fair on both sides. I mean, they can't come here without a job offer either!
Then answer me why there isnt at least 1 high profile project that's ran by an Indian developer?
Um, Anjuta?
Bah. You and your logic! I think my mind is just supressing all thoughts of D3D programming :)
Okay:
Bottom window: 1600x1200 Xine window playing Hellsing Episode 6 (awesome anime!)
Top window: ~1000x700 Konqueror window opened to Fark
Moving the top window results in barely noticible amounts of black areas on the video window. The underlying video doesn't stutter one bit.
This is with NVIDIA's binary drivers, XFree 4.3, and KWin from KDE CVS. Oh, and kernel 2.6.1.
No I didn't. Why do you think I said "MacOS X (as it is now)" in my original post?
The point of comparing to OS X was to provide a point of reference that people could see now.
And what exactly about that is ahead of Mac OS X, as it stands now? I certainly know that 1 and 2 have been there since 10.0, and 3 was added in 10.2.
----------
Quartz "Extreme" accelerates only window compositing. Drawing (ie. everything else) is still done via the CPU. That means if you actually use lots of vector graphics, it'll run dog-slow. Why do you think OS X's UI is still mostly composed of bitmaps? Both FD.O and Longhorn will use OpenGL to accelerate actual drawing, so you can have very rich vector applications without a performance hit. Read Apple's 2002 SIGGRAPH paper for how Quartz "Extreme" works.
like anti-aliasing are completely sorted out, once and for all.
-------
Anti-aliasing has worked for years. What version of KDE/GNOME are you using?
NVIDIA has been pretty amenable to working with the freedesktop.org folks. Just read the fd.o mailing list.
Freedesktop.org is working to put this in. They already have a fully-compositing X that you can download right now. Window movement is pretty good (especially impressive given that its unaccelerated!), but resize is really slow because of very unoptimized code. When it gets its new acceleration architecture, everything should be a lot faster.
Actually, Quartz does not draw line by line. Quartz preserves a bitmap of each window, and when something damages the contents of the window, restores the image from that bitmap. This takes up tons of memory (need window buffers even if window is hidden) but eliminates any streaking.
And resizes on OS X are really slow, though that doesn't have a lot to do with the double-buffered approach. Quartz is just really slow overall.
Anyway, I use OS X 10.2.8 on an 800MHz G4 17" iMac, and it definitely suffers from choppy resize operation.
Okay some tests:
Fluxbox, Konqueror opened to Google News: Streaking.
Fluxbox, Konqueror opened to kdelook: Streaking.
Metacity, Konqueror opened to Google News: No steaking.
Metacity, Konqueror opened to kdelook: Streaking.
Kwin, Konqueror opened to Google News: No streaking.
Kwin, Konqueror opened to kdelook: No streaking.
In particular, kdelook is the only site complex enough to notice streaking with kwin.
Configuration:
2.0 GHz Pentium 4 on an Inspiron 8200
GeForce 4 Go 440 w/ 64MB of RAM
NVIDIA binary drivers, 5336 (RenderAccel on)
1600x1200 15" LCD
640MB RAM
XFree86 4.3.0
Debian sid
KDE CVS
Note: I've got kwin patches that are not in KDE 3.2. If you want to replicate the test, either compile the latest CVS, or use KDE 3.1.x. KDE 3.2's kwin is a new one, and was not highly optimized relative to previous kwin's.
It would be *really* hard to write a compatibility layer for XFree drivers. I looked into doing that myself awhile ago, and while it would be possible, it would involve implementing many XFree86 DDX calls in kdrive. The NVIDIA driver, for example, makes 400 different calls into XFree86. If something like that were to be done, it'd be a long term project. Most importantly, there is no mention of this in the mailing lists.
Maybe what you're thinking is that they plan to release XFree86 with the FD.O Xlibs, which would be doable. It would only include compositing, though, in the sense of supporting the Composite extension, not full window compositing.
I could be entirely wrong though!
Still works just fine. Have you tried Konqueror with another window manager (like Metacity or Window Maker)?
Okay, test performed on Linux 2.6.1, XFree86 4.3.0 (NVIDIA binary drivers), with KDE CVS and Galeon. Machine is a P4 2.0 GHz.
:)
To perform this test, start with a good web browser (firefox, mozilla, konqueror, galeon, whatever). Enable the equivalent of "Opaque Window Moving" on your window manager. Open a browser window and drag it to the bottom-left corner. Now drag it back. What happens?
--------
The window moves?
Open two windows. Drag one across the other. What happens?
---------
The window moves again?
What happens is smearing.
---------
Except it doesn't?
Gross. Ugly. Unacceptable.
-------
It would be, if it happened
The problems you mention are not the fault of X. Its the fault of the applications. Your test *does* show some trailing in Mozilla. But KDE doesn't exhibit these problems, mainly because Qt rocks.
Linking against libraries is a derivative work. Otherwise, copyright would be trivial to defeat. Just take the code you want to use and put it in its own shared library, and voila, no copyright issues!
Its hardly charity. The pro graphics workstation market likes the price/performance of Intel + NVIDIA + Linux. SGI's x86 machines all run NVIDIA. They make a nice bit of change from their Linux drivers. That's why their Linux drivers aren't half-assed like ATI's.
Actually, NVIDIA, anyway, seems reasonably supportive of the efforts. The radical redesign of the driver API is necessary because they want to seperate the OpenGL drivers from the X server, so the X server can do its drawing through OpenGL.
There's tons of BSD licensed code in Linux. But its all the new-style BSD license. The new XFree license is like the old BSD license, with the advertising clause.
Stuff is racing forward at freedesktop.org. They are planning (and already have a lot of code for):
- A fully double-buffered window system
- Vector graphics library (Cairo)
- Fully accelerated drawing via OpenGL
- X-independent OpenGL subsystem
Those features would put X ahead of MacOS X (as it is now) and on a par with Longhorn. And they've made real progress so far --- you can download the FD.O X server today and see the first two features in action.
Its nice to see the XFree86.org folks making the transition to the freedesktop.org smoother by making themselves irrelevent to users. Nice going guys!
Because the Air Force has a sense of humor.
IIRC, the F117A's max loadout is a pair of 2000lb laser-guided bombs.
Let's phrase it accurately. Its not that QE doesn't offer "a complete hardware acceleration scheme." Its more appropriate to say that QE accelerates only a small portion of the graphics system.
My big beef is that people do not phrase it that way! I've heard literally dozens of Mac fanatics spout of about how Quartz "Extreme" offers a fully hardware accelerated GUI! What sickens me is that the Apple fans distort the perception of Quartz "Extreme" even beyond the lofty exaggerations of Apple's marketing department!
I'm not bitching about Quartz "Extreme" as a technology. I think its fine for what it does. I think hardware-accelerating compositing is kinda stupid without accelerating drawing, but hey, Apple's market responds to gimmicks like transparent windows. It just pisses me off that people blow it completely out of perspective.
It does work, it just doesn't have forwards compatibility. You can run a glibc-2.2 app on glibc 2.3, but not vice-versa. That is, of course, obvious!
Don't forget panels and menus. KDE's panels and menus are a lot more customizable. For example, there is no way to put the GNOME menu at the top, and GNOME panels just have the standard-autohide, instead of the "allow windows to overlap panel" option KDE has. The latter is, imho, a perfect compromise between saving screen space and having quick access, because although the panel can be overlapped, it rises to the top when you move your mouse to the window edge. However, unlike with autohide, the panel is usually visible because windows usually aren't overlapping it.
Both KDE and GNOME have repeatedly stated that they are willing to compromise. freedesktop.org is a manifestation of that willingness to compromise. However, what neither group is willing to do is to start over. Throwing out GTK+ or Qt would mean rewriting *everything* in the desktop, and that's just not a practical thing to do.