The developers of Google Earth boast that it works well with older graphics cards, that is due to the fact that is based on an aging codebase and was designed with those components in mind. EarthBrowser (as primitive as it was) had the virtual globe market all to itself from 1998 to about 2002 when I first heard about Keyhole EarthViewer when someone from Keyhole offered to buy earthbrowser.com and my customer list. The code is probably still based on their original code developed back then. I can see that they have added more and more on top of that old code. Believe me, you can really pile new features on top of an old foundation but it just gets harder and harder. It gets harder to add new things and it gets harder to change old ones. Just look at Windows or any product that has been out there for any period of time. EarthBrowser itself has been rewritten twice already and I'm on my third complete re-write. A complete re-write is time consuming, difficult and almost never done for a commercial product due to the time, cost and difficulties in such an undertaking of an established product. However, the benefits of such a re-write are immense, for an example, look at the transformation of MacOS since Steve Jobs came back.
Back to Google Earth. Google seems good at publishing APIs for their web services, like Google Maps. Unfortunately for people who use them, they reserve the right to yank the rug out from under you at any time with their licensing terms. The Google Earth API is effectively KML, perhaps they are going to introduce something new after the acquisition of Sketchup which has a reportedly nice Ruby API, but for now it is just static data with the weakest possibility of time based animation through some kludgy use of the "network link." By the way, what kind of hyperlink is not a "network" link? Just wondering.
I don't want to help Google with any of it's problems since they are the main competitive threat to EarthBrowser. I tried writing a file format for EarthBrowser back in 2000 (version 1) that would use static files to control actions in EarthBrowser. It was a very difficult to thing to keep up with. Any new action had to be first coded into the program, then an interface to that code provided and access through the file format. Tweaking that was a nightmare so I tried making my own tiny programming language to embed in the files to provide more flexibility. It worked OK, but that just added another layer of complexity along with the file format and the hand coded feature linkings. You can see the dilema they are facing by adding more and more features into KML that need to be supported in current and future GE versions. They need a rewrite, but guess who will have a new virtual globe out soon (besides EarthBrowser)... Microsoft. I don't know what MS has in store for us but from the looks of Flight Simulator X, it will blow GE out of the water.
Here is discussion of one of the extensions someone has made for Google Earth using KML. It is just so kludgy...
I've learned the lesson of trying to make a static file format control a virtual globe. The next version of EarthBrowser will feature a fully scritable game engine which users and developers can add their own data types and visualizations directly on the globe. As an example, it will be possible to code a module that will download raw data from any source (e.g. NASA) and process it for display on the globe. From this scriptable code base it will be easy to create a KML converter and easily update it with new versions of KML with few changes to the actual code base.
I'll leave you with an early screen shot of EarthBrowser under development: