[Kstars-devel] Ideas for Adding a Spatial Index to KStars

[James Bowlin]

On Thursday 22 June 2006 01:48, Jason Harris wrote:
> The other difference is, whereas I passed a QList<int> reference as an 
> argument to provide the list of visible HTM indices, you call 
> "skyIndex->getView()"  What do you think about naming this function 
> something more descriptive, like visibleIndexes() or viewIndexes()?

I agree that the names you suggest are much better than getView().  
I would tend to prefer visibleRegions() even though is actually returning
indices.  Since we don't have a SkyRegion class anymore I don't think the
fact that it is returning a list of ints will be confusing.  I think
visibleRegions() is more descriptive of what is actually being returned
since "indexes" can mean a lot of different things.  But I will defer
to your judgment on the naming.  I prefer the "visible" prefix.

> Anyway, I still think it's a good idea to pass the list of indexes as an 
> argument to the draw function; that way the Components don't have to 
> know about SkyIndex.

Here I strongly disagree.  I have two reasons.  The first is on general
principle: I think that whenever something can be moved out of the parameter
list and into a data member it should be.  For example, I would love to get
rid of the extra parameters in the skyMap->toScreen() call and move them to
data members in the SkyMap class.

The second reason is more pragmatic.  The best way I know to deal with 
drawing objects that are in more than one region is with the drawID I had
brought up earlier.  I thought the best place for holding the global drawID
was in the SkyIndex.  Since some components need the drawID and some don't,
I had two ideas of how to pass the global drawID to the components but both
of them assume that each component has a skyIndex member.  One way would be
to include it in the visibleRegions() ( or visibleIndexes() ) call:

    QList<int> *visibleRegions( int *newDrawID=NULL );

The other way is to just add a simple "int drawID()" method to the SkyIndex
class.  It is possible, perhaps likely that we may need to have other closer
interaction between the SkyIndex and the components.  For example, if we want
to try changing the "region" QHash of QList's of stars to an array (or QList)
of QLists of stars to see if that gives us a noticeable speed boost, the
StarComponent will want to know the size of the index so it can allocate the
array.

I suggest we bite the bullet now, and add a SkyIndex as part of the
initialization code of the components and then we don't have to worry
about it again.  Again, I think it is a win for us to move complexity
from the draw loop to the initialization code.

For testing/bootstrapping I was thinking that we could make a simple
stub SkyIndex that thinks everything in the sky is in one region.


-- 
Peace, James