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

[James Bowlin]

On Thursday 22 June 2006 10:02, Thomas Kabelmann wrote:
> @James
> I think we are talking about different things. As Jason mentioned in his post 
> of your mail, we can't remove the composites. The composites compose the 
> structure and just the components are doing real work, like drawing. I guess 
> you're thinking that StarComponent is 1 star. It's not so. For efficiency 
> reason we have stored all stars in 1 list in this component. In a perfect 
> object orientated world each StarComponent would represent 1 star, but that 
> would be a big performance hit. With our current implementation there is no 
> need for a static list in the composite. We can replace the list in the 
> component with a hash of lists.

First a minor point:  I never suggested a static list in the composite.
I suggested either a static list in the component or a instance list
in the composite.

I understand that all of the stars are in one StarComponent for efficiency
and there is no StarComposite class.  I applaud this move.  From what I've
seen in the code, this move was done for the stars but not for any of the
other components I've seen such as MilkyWay*, ConstellationLines*, and
the guides such as the coordinate-grid and the horizon.

What I've seen in the code is that you broke the strict object oriented
model for the stars to increase the efficiency but are keeping all of
the other components inefficient.  I want to make what we do for the
stars the general rule so all of the drawing code is as efficient as
possible.


-- 
Peace, James