I recently wrote about problems with Google Earth [1]. In comments it was pointed out to me that there are some Debian packages of it in contrib. Installing the package ttf-bitstream-vera solved the font problem and running it directly (not through ssh -Y) on a machine with DRI support made it run reasonably fast on a machine with identical hardware to my mother’s.
The animation is quite slick when the hardware works, and I have used it a bit.
However I’m still disappointed in the program. The animation should be disabled for hardware that doesn’t support it at a reasonable speed (a reasonable default would be to disable animation if the display is :10.0 so that it doesn’t try to do animation over ssh). Also the feature of having movement continue should be disabled if there is any question about the performance. When performance (of scrolling and network access) is good it’s nice to be able to swipe with the mouse and have the scenery slide past until you tell it to stop. When performance is bad it’s annoying to have it keep trying to slide somewhere and make the entire machine run slowly.
If you really just want to look at static aerial photos on a machine with minimal spec graphics, then why don’t you just use the “satellite” view on maps.google.com? It’s the same imagery.
No, disabling the 3D over ssh isn’t a reasonable response. The problem is simply that your X server doesn’t support accelerated indirect rendering – if it did, it would be perfectly usable. There’s also no requirement that display 10 be remote, so using that as a heuristic would result in odd behaviour occasionally.
Robert: Good idea, I’ve just tested that and it works well.
Matthew: How do I determine if my X server does support such things (apart from running Google Earth and seeing if it sucks)? As for display 10 being remote, you are correct, but the number of people using 10 physical displays on one machine is vanishingly small.