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

[Jason Harris]

Great, it looks like we are converging now.

On Jun 23, 2006, at 3:53 AM, Thomas Kabelmann wrote:
> Well, I see we talked on cross purposes. I was talking on the base of
> StarComponent and you were talking on base of MilkyWayComponent/ 
> Composite. No
> I understand your problem :-)
>
Yes, it was a good explanation of the issue in your last email, James.

> There are 2 common ways to optimize the components/composites.  
> First way is to
> put all objects in 1 component, as we did in StarComponent,  
> DeepSkyComponent
> etc. Second way is to put some additional logic in the composite.  
> This means
> that instead of simply sending each subcomponent a draw message the  
> composite
> knows which objects really have to draw on the map.
>
A simple criterion for wondering whether a group of items should be  
stored as individual Components in a sub-Composite, or in a single  
Component, is to ask the question:  "Do we usually manipulate these  
items as a group, or individually?".  If the answer is "as a group",  
then I think it makes sense to put them inside a single Component.   
For example, we probably need SolarSystemComposite, because the items  
it contains are unique, and we need some glue-code in the Composite  
to handle special cases.

I think for things like the Milky Way and Constellation Lines, we  
should consider constructing a Component that can handle them.  I  
like James's idea of adding a MilkyWayPolygon class, and making  
MilkyWayComponent contain a QList<MWPolygon>.  Similarly, we could  
have a CLine class handled as a list in ConstellationLinesComponent  
(or maybe CSegment could be adapted to the purpose).

> The next thing is the implementation of the index list. We are now  
> so far that
> we want to use a QHash of QLists. Currently we use a pure QList for  
> storing
> all data of a component (stars, deep sky objects). This will  
> replaced by the
> hash of lists. I've proposed the idea of having a templated  
> RegionList class
> which hides the details of the implementation. We use iterators for
> traversing this list. As C++ gives us templated classes, why not  
> use this
> feature? We are just having 2 additional classes.
>
Why can't we use an existing templated Qt container?  I guess for the  
flexibility of choosing the "backend" (QHash, QVector).  But do we  
really anticipate that different containers will outperform others  
for different Components?  Oh, actually, I guess we'd put the HTM  
visibility code in RegionList.  But does it belong there?  Different  
Components will need to handle visibility checks in different ways.   
I'm especially thinking of extended items like MilkyWayPolygon.

> There will be no measurable loss of speed in this implementation.  
> The big
> advantage is, that we don't need to add to every component or  
> composite the
> hash of lists. We just add the region list.
That's not a huge advantage; we're going to have to make changes in  
all the Components anyway.

>
> I will summarize the current situation were we agree:
> - components like starcomponent still remain
> - components/composites like milkyway need to be changed
>   + we have 1 component with all data
>   + or we have 1 smart composite which draws visible components
>   + we should decide for every single case what the best solution is
>
Let's talk about which cases we'll really want a sub-Composite for.   
I vote for:

SolarSystemComposite: Keep.   (each body is sufficiently unique, I  
think we need the flexibility in this Composite)

MilkyWayComposite: Switch to Component.  (need a MWPolygon class)
ConstellationLinesComposite: Switch to Component.   (need a CLine class)

CoordinateGridComposite: Switch to Component?  (maybe we need a more  
general SkyLine class that could be used by const. boundaries, const.  
lines, and the coord grid....and the angular ruler, even)

Regarding the coordinate grid, James pointed out a while ago that  
it's very slow to draw so many individual line segments (especially  
in antialiased draws)...maybe it would be faster to store sections of  
each circle in the grid as unclosed QPolygons (a.k.a. polylines)?   
I'm not sure about this, just thinking out loud.

> I think we come finally to a solution.
>
> Regards,
> Thomas
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
>