Re: [guide-user] Using OpenGL for object display.
Bill J Gray Oct 24 3:29 PM
Unfortunately, I don't see that OpenGL would really help very much.
The places where Guide tends to be slowest involve display of asteroids
and artificial satellites. If you turn all the asteroids in 'mpcorb' On
or Auto, or turn all artificial satellites from 'all_tle.txt' On or Auto,
Guide will suddenly become much more glacial. This is partly a matter of
reading in the data, but also a matter of doing lots of math (the graphics
scarcely register in all of this).
You can also get the program to slow down when displaying stars, but
you usually have to be running from the DVD to get that to happen; if you
have installed to the hard drive, it'll be fast. So most of my efforts to
speed up the program have been aimed at asteroids and artificial satellites.
I've had some success with asteroids, by doing some pre-calculation.
For each asteroid, Guide computes a rectangle (in ecliptic coordinates)
within which the object is apt to be over a fifty-day time span, as well
as a maximum magnitude it will reach. When drawing a screen, it can
usually look at these data and say: "We don't even need to think about
this object, either because the object is too faint to possibly appear
on this map, or because it won't be anywhere near the current screen area."
(Though it _does_ grind to a halt, briefly, when you change Guide's date
to be outside the current fifty-day span. When you do that, it has to
stop to recompute all these data. But fortunately, that's not very
common in "normal" use.)
I have not had quite as much success with artificial satellites...
still looking for some "clever" schemes for these.
There's one thing I could do that would probably result in some dramatic
improvements for both of these. At present, all the work is done in a
single thread. At least in theory, it should be possible to split up the
asteroids (or artsats) to be shown among all the processors; if you have
a quad-core processor, for example, things should run about four times
as fast. This is the most likely "next step".