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

[Akarsh Simha]

> If you agree with all of the above then I think the next step is to 
> implement the two lists.  The named stars get created with a 
> constructor (or whatever) and go into a structure much like we have
> right now.  The unnamed stars will go into a StarBlock and get 
> initialized with the memcpy() and init() tricks.

I'm fine with this.

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

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.

> This will require two different draw() loops for the stars.  For now
> both these loops will reside inside of StarComponent.  There will be a 
> loop just like what we have now for drawing the named stars and there 
> will be a 2nd, very similar loop that loops through the StarBlockLists
> for drawing all of the unnamed stars.  Since we are only dealing with
> global stars for now, each StarBlock list will have at most one 
> StarBlock.  So the draw() routine in StarComponent would call 
> drawNamed() and then call drawUnnamed().

Acceptable.

> I suppose you could use polymorphism and some abstraction to cram them
> both together into one loop but I don't think we would really gain us 
> very much.  We want to move decision making out of the inner loops 
> whenever we can.

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

> This is great work you've done so far.  I'm impressed that you've gotten 
> stars to load so quickly so soon in the project.  We should really be 
> thinking about going up to 10 million stars before the end of the 
> summer.  I think our current (planned) data structures could handle 
> that.   Does anyone know if there are 10 million stars that would be 
> available for us to use?   I don't think our code would have to change 
> at all.  I think our code (and file format) can be designed so someone
> can just plop in the larger data file and it will all just work.

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.

Regards
Akarsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20080606/6f4443a3/attachment.pgp