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

[Jason Harris]

Hi James,

Fantastic results, thanks for looking into this.

On Tuesday 13 June 2006 09:58, James Bowlin wrote:
> I did two simple things.  First, in starobject.cpp I removed the color
> calculations.  It now appears that these were not the major problem so
> they might be reinstated with little or no speed penalty.  If they are
> a problem then we should cache the color for each star as a data member
> in each StarObject.  If these colors need to be changed when an option
> changes then the changes should be done right after the option changes
> and not on every draw.  If changing colors is still causing a problem
> even after the colors are cached then we can split the stars into
> separate lists depending on color and then draw each list so we don't
> need to change the color in the inner loop (but I doubt this step will
> be needed).
>
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.

> Second, in skycomponents/starcomponent.cpp, I first put in a continue;
> right after the star was drawn which disabled the labeling.  These two
> changes gave a speed boost of roughly 2!  Next, I broke out the labeling
> code into it's own loop so the font and color setting only needs to be done
> once.  The stars code is consistently faster than the Solar System now
> and most of the speed boost remains.
>
Great!

> 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.

> Here is the star labeling loop from skycomponents/starcomponent.cpp so you
> can see what I'm talking about.  It might be missing some essential
> features but it seems to work here.
>
(snip)

I'll work on this stuff tonight after work.  Thanks!

Jason

-- 
-------------------------------
KStars: http://edu.kde.org/kstars
Forums: http://kstars.30doradus.org