[Kstars-devel] comparing elapsed time for drawing under 3.5 and 4.0

[James Bowlin]

On Tuesday 13 June 2006 19:25, Jason Harris wrote:

> You're right, there's no point recomputing the colors for every star in the 
> draw loop!  Sorry, I should have caught this before committing.  What about 
> having a static QMap<QColor> member variable in StarObject that stores the 
> color values for the 7 spectral types?  We could then add a function 
> StarObject::updateColors() which is called when the colors need to be 
> recomputed (either because the user changed the saturation level, or toggled 
> the antialiasing option).  The existing function StarObject::color() would 
> then just return the appropriate value from the QMap.

Sounds good.  A QHash may be a little bit faster than a QMap.  I would have
added a pointer in each star but I am beginning to appreciate your
desire/need to conserve memory.
 
> > I think we can improve the speed further by caching result of the
> > toScreen() calculation in a StarObject data member when we are drawing the
> > stars in the first loop so that calculation does not need to be repeated in
> > the second loop that draws the labels.  If there is ever a chance that the
> > labels will need to be drawn when the star itself has not be drawn then we
> > will need to implement the drawID data member in StarObject so when know
> > whether or not a new QPointF needs to be calculated.
> >
> Hmm, maybe.  It's expensive from a memory-usage point of view to add this to 
> all 126,000 StarObjects, when only a very small fraction of them will ever 
> need a label.  I'm hoping to be able to add many more stars to our catalog 
> for 4.0, so this would only get worse.

You're probably right.  We'll have to see.  I think that your idea of
getting rid of all the transcendentals  from toScreen() would be much
better than caching.

If we do want to cache, one way to do it would be to subclass StarObject
to LabeledStarObject (or something) and only put the label field and
cached QPointF fields in the LabeledStarObject.  This might actually
save space since the vast majority of stars have no label (AFAIK).
But I am not suggesting that we do this now.  Just talking and thinking.

Since we are bumping our heads on speed problems maybe the time is now
ripe to implement your idea.  I think it might be very, very easy.  The
hard part would be to compute the nine matrix components for the
transformation from celestial x-y-z to screen x-y-z (we need screen z
for clipping at the celestial horizon (I think)).

But we can keep the current toScreen() function (or something very much
like it) for computing the matrix components.  We just send the current
toScreen() the [ra, dec] of the three unit vectors in the x, y, and z
directions and the three QPointF's returned should give us six matrix
components.  I'm not certain of the the screen z component but I think
the variable called "c" which is compared to 0.0 for seeing if a point
is on the "back side" of the celestial sphere would be a good first guess.

Ironically, storing the x-y-z of each star would take more space than a
single QPointF (assuming the QPointF is just the size of two doubles).

I'm thinking about trying this out in the 3.5.x branch to see if it really
works.
 

-- 
Peace, James