[Kstars-devel] Kstars optimization

[Jason Harris]

Hello,

On Tuesday 28 November 2006 08:33, Prasanna Krishnamoorthy wrote:
> > This is really surprising, especially since the main window has hardly
> > any GUI elements!  What happens if you profile while using a style other
> > than plastik?  My guess is there must be something wrong here that has
> > nothing to do with KStars.
>
> I'm using Xubuntu here, with Kstars installed. So I'm not quite sure
> how to change the style :-). I'll find out how to do that. Is there a
> 'lighter' KDE style that you'd recommend?
>
You can change the style in the KDE Control Center (kcontrol); I'm not sure if 
this is "rebranded" on Xubuntu.  In the menu at the left, select "Appearance 
& Themes", then "Style".  I don't know which style to recommend; most people 
regard Plastik as both beautiful and efficient, so I'm pretty surprised to 
see that you're finding that it is using 50% CPU.  There is a style called 
"Light Style", so you might try that.

> > I've thought about this in the past.  It may be worth trying.  Again, at
> > low zoom level extreme trig accuracy is probably unnecessary in most
> > cases.  There will be situations when we want the real trig values, but
> > in most cases, an interpolated grid should be good enough.
>
> Great! I can get to work on that. Is there a list of situations where
> 'real trig' values are needed? I'm thinking of a wrapper function with
> a run-time flag for 'real Vs fast'. Gcc should be able to optimize out
> the function-call or inline it.
>
It depends mostly on the zoom level, I think.  If we have just a single static 
lookup table, then there will be a single threshhold zoom level above which 
we will want to switch from the LUT to real trig values, because at higher 
zoom levels errors in position will be more noticeable.  I think we should 
decide on this zoom level empirically.  We can draw some set of objects 
twice, once with LUT coordinates, and one with real trig coordinates.  Then 
zoom in until the pairs of objects deviate from each other.

Performance won't suffer much at high zoom because most of the points are 
off-screen and therefore don't need to have their positions computed.  

> > A slight improvement over a static lookup table over the full range of
> > angles is to dynamically create lookup table values for the range of RA
> > and Dec values that are currently being displayed.  The advantage is
> > that you can get a grid resolution that changes with zoom level, so it
> > is always a good match to the pixel resolution.  The disadvantage is
> > that it's more complicated, and you might need 4 lookup tables (for the
> > displayed ranges in RA, Dec, Az and Alt).
>
> I'll give a quick shot at the plain interpolated LUT first. I can
> verify the standard error, over a default range, but am not sure how
> we can quantify the error margin for Kstars correctly. Is there any
> level which you'd consider 'acceptable', or perhaps this could be a
> run-time option? Fast vs Accurate would be good for the user to choose
>
Once we see the implementation, perhaps it will be clear how to optimize the 
tradeoff of Fast vs. Accurate.  For now I think the threshhold zoom level 
will be fine.

> :-).
> :
> > Thanks a lot for the feedback.  Just so we can be clear of your intent,
> > are you saying that you want to try implementing a lookup table, or are
> > you just advocating the idea of doing so?
>
> I'll work on the LUT as soon as I get some time - perhaps this week
> itself. I need to get this up and running so the state can save as
> much money on the hw as possible.
>
> Will send you a patch as soon as I'm done with testing.
>
Fantastic!  That's what I like to hear :)

You are developing against 3.5, I presume?  We're technically not developing 
that branch anymore; no new features are allowed to be committed in it.  I am 
willing to port your changes to the development branch (which will eventually 
become KDE4).

thanks,
Jason
-- 
Jason Harris
jharris at 30doradus.org