does that mean that this technique could be used by 3D game engines to acomplish the same effect?
The technique is used by 3D game engines, trivially: that's the kind of perception you should be getting when moving through a virtual world. It's just that it is more noticeable when you move rapidly side-to-side then when you move forward (which is what you usually do).
Yes, those animated GIFs achieve a 3D effect. They do so via motion, however, not via stereo--a completely different mechanism. You can actually be blind to depth from motion and still perceive stereo and vice versa. The fact that it works by alternating between stereo pairs has to do with the way motion perception works.
Using motion to indicate depth has a long history in computer graphics. The obvious problem is that it requires the viewpoint or the object to move significantly, not always desirable.
Images that use motion to indicate depth don't have to look as horribly jittery as those animated GIFs: the effect works just as well with nice, smooth motion sequences. So, get out your camcorder and make some nice animated images.
Did I mention coding in Java is much easier than fighting with ancient macros in C or C++?
That depends on the applications. Try writing numerical code or access shared memory from Java. I think Java just got feature-frozen too early, and what we have ended up with is a decent language, but not one that will replace C++.
I think C# has a better chance of taking over from C++: C# is mostly like Java but adds many of the features necessary for a general purpose language. If worries about C#'s ownership can be resolved, I think it may end up being more successful than Java, both on commercial and on open platforms.
Well, let's see, why wouldn't you want to use Swing?
Swing is a Java-only toolkit; people program in many other languages.
Swing is a Sun-proprietary toolkit; there is no independent implementation, either commercial or free, and it isn't clear anybody will ever be able to create one.
Java+Swing fails to have native look-and-feel on X11, it doesn't integrate well with desktops, it doesn't pick up themes or preferences, it doesn't let software get at even the most elementary information from the user environment, etc.
Java+Swing is a decent, popular cross-platform environment, albeit a Sun+proprietary one. And Swing is pretty general, complete, and easy to program in.
But Swing is certainly not a panacea for cross-platform software development, and it is at best a mediocre compromise for writing Linux desktop applications.
There is a disturbing trend of recent articles that engage in Qt/KDE bashing.
When people say that they think a dual-licensed GUI toolkit is bad for the goals that open source software is trying to achieve, or when they say that a C++-based toolkit won't do for them, that's not "bashing", that's an honest and straightforward assessment of their own needs.
If the KDE project doesn't want to listen to the community or is convinced that these objections don't matter, that's fine: respond in a calm and rational manner or be quiet. But accusing people of "bashing" because they disagree with you only makes KDE supporters look irrational. And KDE already has a big credibility gap on licenses because of the original QPL/GPL disaster. Maybe you should actually start listening.
Clue to the author: Qt is made by a company called Trolltech. Companies exist to make money for their employees and shareholders. One of the ways they do that is by (gasp) marketing themselves on the web.
Yes, but software companies also try to make money by entangling their users in a web of sunk costs (training, tools) and proprietary interfaces. That is why open source advocates are often suspicious of open source efforts that come across as "too corporate".
That particular company has gone to great lengths to accomodate free software developers; but they still have to make money somehow.
Well, that is nobody's problem but theirs; nobody is under any obligation to use their software.
And, frankly, on balance, I think Troll Tech has gotten by far the better deal out of KDE's use of their toolkit. I think without KDE, Troll Tech would simply not exist anymore, while Linux probably would have a more unified and better desktop experience than the current Gnome/KDE split.
The article says the Xlib API function prototypes are still K&R.
The Xlib API still has support for K&R, but it also has prototypes.
In fact *any* improvement to Xlib be great for everyone. This suggest it would be a great area for somebody like IBM to fund.
Xlib is just a C library for accessing the X11 protocol. There are several libraries and toolkits that don't go through Xlib at all (e.g., CLX, Escher). But Xlib is pretty good at what it does; it's complicated because X11 has a lot of features.
There has been some work on a new low-level C library for accessing X11 servers, but the community just doesn't seem to have that much interest.
You may notice that the "gold standard" of GUIs that people like to hold up for Linux, Microsoft and Apple, are not cross platform. Neither company wastes time trying to build something that works well with a GDI, X11, and DisplayPDF backend. And there are good reasons for that.
Picking APIs that can be supported on multiple platforms is a lot of work, and implementing them on multiple platforms is even harder. Furthermore, some things simply cannot be supported well in a cross-platform manner, and conventions from one platform inevitably spill over to another platform.
For example, many cross-platform toolkits have no notion of remote displays. Even if the toolkit supports it, application programmers still hardcode assumptions about specific environments (e.g., on Windows, preferences are usually tied to the machine, while on X11, they should be tied to the display). The wxWindows, Mozilla, Qt, and Java/Swing toolkits are full of such compromises and assumptions, as are applications written in them.
Developers of a high quality Linux desktop should write specifically to X11, the native Linux graphics subsystem and not waste time or effort on any kind of cross-platform support; the competition isn't wasting time either. Cross-platform toolkits have their uses (I usually use wxWindows or FLTK), namely for when you really want to create a cross-platform application, but they are not a good choice for the core apps.
Of course, many people who do use cross-platform toolkits and notice that they often support X11 less well than Windows (because of the smaller market) blame X11 and want to fix the problem by replacing X11 with something just like GDI. To those people I suggest: contribute to an open source Windows clone if you like; don't try to make Linux into Windows.
Slashdot Mirror
does that mean that this technique could be used by 3D game engines to acomplish the same effect?
The technique is used by 3D game engines, trivially: that's the kind of perception you should be getting when moving through a virtual world. It's just that it is more noticeable when you move rapidly side-to-side then when you move forward (which is what you usually do).
Yes, those animated GIFs achieve a 3D effect. They do so via motion, however, not via stereo--a completely different mechanism. You can actually be blind to depth from motion and still perceive stereo and vice versa. The fact that it works by alternating between stereo pairs has to do with the way motion perception works.
Using motion to indicate depth has a long history in computer graphics. The obvious problem is that it requires the viewpoint or the object to move significantly, not always desirable.
Images that use motion to indicate depth don't have to look as horribly jittery as those animated GIFs: the effect works just as well with nice, smooth motion sequences. So, get out your camcorder and make some nice animated images.
Doesn't some linux zealot happen to have these sources lying around?
ftp.kernel.org has the complete history, as do the version control archives.
Did I mention coding in Java is much easier than fighting with ancient macros in C or C++?
That depends on the applications. Try writing numerical code or access shared memory from Java. I think Java just got feature-frozen too early, and what we have ended up with is a decent language, but not one that will replace C++.
I think C# has a better chance of taking over from C++: C# is mostly like Java but adds many of the features necessary for a general purpose language. If worries about C#'s ownership can be resolved, I think it may end up being more successful than Java, both on commercial and on open platforms.
Java+Swing is a decent, popular cross-platform environment, albeit a Sun+proprietary one. And Swing is pretty general, complete, and easy to program in.
But Swing is certainly not a panacea for cross-platform software development, and it is at best a mediocre compromise for writing Linux desktop applications.
There is a disturbing trend of recent articles that engage in Qt/KDE bashing.
When people say that they think a dual-licensed GUI toolkit is bad for the goals that open source software is trying to achieve, or when they say that a C++-based toolkit won't do for them, that's not "bashing", that's an honest and straightforward assessment of their own needs.
If the KDE project doesn't want to listen to the community or is convinced that these objections don't matter, that's fine: respond in a calm and rational manner or be quiet. But accusing people of "bashing" because they disagree with you only makes KDE supporters look irrational. And KDE already has a big credibility gap on licenses because of the original QPL/GPL disaster. Maybe you should actually start listening.
Clue to the author: Qt is made by a company called Trolltech. Companies exist to make money for their employees and shareholders. One of the ways they do that is by (gasp) marketing themselves on the web.
Yes, but software companies also try to make money by entangling their users in a web of sunk costs (training, tools) and proprietary interfaces. That is why open source advocates are often suspicious of open source efforts that come across as "too corporate".
That particular company has gone to great lengths to accomodate free software developers; but they still have to make money somehow.
Well, that is nobody's problem but theirs; nobody is under any obligation to use their software.
And, frankly, on balance, I think Troll Tech has gotten by far the better deal out of KDE's use of their toolkit. I think without KDE, Troll Tech would simply not exist anymore, while Linux probably would have a more unified and better desktop experience than the current Gnome/KDE split.
The article says the Xlib API function prototypes are still K&R.
The Xlib API still has support for K&R, but it also has prototypes.
In fact *any* improvement to Xlib be great for everyone. This suggest it would be a great area for somebody like IBM to fund.
Xlib is just a C library for accessing the X11 protocol. There are several libraries and toolkits that don't go through Xlib at all (e.g., CLX, Escher). But Xlib is pretty good at what it does; it's complicated because X11 has a lot of features.
There has been some work on a new low-level C library for accessing X11 servers, but the community just doesn't seem to have that much interest.
You may notice that the "gold standard" of GUIs that people like to hold up for Linux, Microsoft and Apple, are not cross platform. Neither company wastes time trying to build something that works well with a GDI, X11, and DisplayPDF backend. And there are good reasons for that.
Picking APIs that can be supported on multiple platforms is a lot of work, and implementing them on multiple platforms is even harder. Furthermore, some things simply cannot be supported well in a cross-platform manner, and conventions from one platform inevitably spill over to another platform.
For example, many cross-platform toolkits have no notion of remote displays. Even if the toolkit supports it, application programmers still hardcode assumptions about specific environments (e.g., on Windows, preferences are usually tied to the machine, while on X11, they should be tied to the display). The wxWindows, Mozilla, Qt, and Java/Swing toolkits are full of such compromises and assumptions, as are applications written in them.
Developers of a high quality Linux desktop should write specifically to X11, the native Linux graphics subsystem and not waste time or effort on any kind of cross-platform support; the competition isn't wasting time either. Cross-platform toolkits have their uses (I usually use wxWindows or FLTK), namely for when you really want to create a cross-platform application, but they are not a good choice for the core apps.
Of course, many people who do use cross-platform toolkits and notice that they often support X11 less well than Windows (because of the smaller market) blame X11 and want to fix the problem by replacing X11 with something just like GDI. To those people I suggest: contribute to an open source Windows clone if you like; don't try to make Linux into Windows.
Even if the Eolas Patent were not obvious to someone skilled in the art, there is prior art. For example, Pei Wei's Viola browser supported applets.