[Kstars-devel] INDI Library v0.6 in SVN

[James Bowlin]

On Sat July 28 2007 3:02 am, Jasem Mutlaq wrote:
> IMO, just make your changes against trunk as there is
> still time for us to test HTM thoroughly. Have you had
> any chance to run benchmarks comparing pre-HTM and
> post-HTM KStars?

No I haven't.  I have not been able to get the timing code to work.
For example, there is code in SkyMapComposite like:

//  QTime t;
    //1. Milky Way
//  t.start();
    m_MilkyWay->draw( ks, psky, scale );
//  kDebug() << QString("Milky Way  : %1 ms").arg( t.elapsed() ) << endl;

I uncommented the timing code but I got only zero or a blank line
to print out.  

I am able to zoom all the way out then click-and-drag the celestial
sphere around so it almost blurs.  But this speedup can't be due to
the index alone because it will only give us at best less than a factor
of two when the screen is fully zoomed out.  I think the
hightlightConstellation() function in skymapdraw.cpp was really slow.
I stopped calling it which may be where most of the speedup came from.

While developing, I made sure the index was working by setting the
radius of the index aperture to roughly one half the screen size so
only objects in the central quarter of the screen (plus a little
extra) got drawn.

Since the drawing is fast zoomed out and since I can see that fewer
objects are being drawn when zoomed in, I have a high level of
confidence that we are getting an even bigger speedup when zoomed in.

> We can probably ask KDE SVN admins to completely
> remove the kdeedu_htm directory manually.

I think I found my error:  unlike most svn subcommands, revert
requires the -R option in order to recurse.

I had already deleted kdeedu_kstars_htm and then filled it with
a fresh copy of the kdeedu trunk, closely following the
instructions Thiago Macieira had given me.  Now that I know how
to revert, I should be back in business.

Since I'm now constructing the branch correctly, it should be
really easy to merge it back with the trunk whenever we want.
One of the primary benefits of keeping the indexed code in a
branch for now is that it will make it easy to do head to head
timing comparisons on the same machine once we can get those
darned timers working again.  Also, I think we may have trouble
compiling the HTM code we got from Johns Hopkins on some machines.
If we had plopped it right into the trunk then we might have stopped
someone right in their tracks forcing them to help fix the HTM code
before they could continue their own development work.

Finally, when I started working on the HTM code, I wasn't sure how
buggy it was.  We didn't want to suddenly make KStars all crashy.
But I've found that as long as I give it sensible data, it seems to
behave sensibly.  

I'll continue working on the branch for now.  I should have it ready
for checkout before the end of the weekend.  Once others are able
to get the branch to work on their systems, we can think about merging.

Does this sound okay?


-- 
Peace, James