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

[James Bowlin]

On Sunday 11 June 2006 17:48, Jason Harris wrote:
> One exception is Stars.  In 3.5, Stars take less time than Solar system or 
> Deep sky, whereas in 4.0, Stars take the most time of any category.  I think 
> this may be due to the fact that I use drawEllipse() to render stars in 4.0, 
> whereas in 3.5, we precached star pixmaps, which were then scaled and drawn 
> to the screen with bitBlt().  I thought that drawEllipse() would surely be 
> faster than scaling pixmaps for each star, but maybe I need to look again...

I think I've found and fixed a lot of the speed problem with the stars in
integer mode.

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

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.

When I re-enabled the color setting code in starobject.cpp, (but kept the
labels in their own loop) the speed dropped to roughly the same as the speed
for the Solar System. 

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.

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.

    if ( checkSlewing || !Options::showStarMagnitudes()  || !Options::showStarNames ) return;
    
    maglim = Options::magLimitDrawStarInfo();
    psky.setPen( QColor( data()->colorScheme()->colorNamed( "SNameColor" ) ) );
    QFont stdFont( psky.font() );
    QFont smallFont( stdFont );
    smallFont.setPointSize( stdFont.pointSize() - 2 );
    if ( Options::zoomFactor() < 10.*MINZOOM ) {
        psky.setFont( smallFont );
    } else {
        psky.setFont( stdFont );
    }

    foreach ( SkyObject *o, objectList() ) {
        StarObject *curStar = (StarObject*)o;

        // break loop if maglim is reached
	if ( curStar->mag() > maglim ) break;
        QPointF o = map->toScreen( curStar, scale );
        // draw label if currently on screen
	if (o.x() >= 0. && o.x() <= Width && o.y() >=0. && o.y() <= Height ) {
            bool drawName = ( curStar->name() != i18n("star"));
            curStar->drawLabel( psky, o.x(), o.y(), Options::zoomFactor(),
                                drawName, Options::showStarMagnitudes(), scale );
        }
    }
    psky.setFont( stdFont );



-- 
Peace, James