[Kstars-devel] Binary star data loading accomplished in Branch!

[James Bowlin]

On Thu June 5 2008, Akarsh Simha wrote:
> So the StarBlock idea will use the structure that we earlier
> discussed off this thread, namely that where we have a:
>
> TrixelList containing StarBlockLists
>    |_ StarBlockList containing StarBlocks
>        |_ StarBlocks containing StarObjects

The TrixelList should be an array of StarBlockLists indexed by trixel id 
so we can quickly grab the StarBlockList associated with any given 
trixel.  Perhaps this is exactly what you meant, but I wanted to be 
sure it was clear.

> And, we implement an LRU Cache. We will allocate a pool of StarBlocks
> and store pointers to them under the StarBlockLists. We also keep
> track of how old a StarBlock is. An unused StarBlock can be snatched
> off for use whenever we need StarBlocks.

Yep.  One way to keep track of the age of a StarBlock is to give each
one a drawID field.  Each time a StarBlock is drawn we set its drawID
to the current drawID (currently stored in the HTMesh object).  The
LRU cache will allow us to quickly get the oldest SB but it won't tell
us how old it is.

> I find it easier to recurse over the two lists in one method itself.

Whatever is easiest (as long as it doesn't slow things down).

> I'd love to see mag 16 stars in KStars. It'll be more helpful when I
> go observing with a new scope whose arrival I'm awaiting! Besides,
> we'll only get more professional and better. I too think that 10
> million stars will be feasible within the current structures we have.

Does a mag 16 limit roughly translate to 10 million stars?


-- 
Peace, James