[Kstars-devel] RFC: KStars GSOC: data pipelining and OpenCL.

[Akarsh Simha]

> AFAIR conversions of coordinates is not worst bottleneck. Last time I checked (1
> or 2 years ago) drawing of constellation lines and borders and coordinates grid
> very much to my surprise. Any proposals to improve performance must be backed up
> with profiling/benchmarks. Otherwise it's too easy to fall into trap of
> optimizing wrong thing.

Even with the USNO NOMAD catalog? That is a bit hard to believe,
although it might be the case. With the USNO NOMAD catalog, KStars
crawls when zoomed in on Sagittarius.

> Furthermore we can get ~10x performance boost (uneducated guess) by changing
> representation of sky point. Currently it's represented by two angles and
> conversions between different coordinate systems are quite costly: 5 or 6 calls
> to trigonometry functions.
> 
> Much more convenient scheme is to store points as 3D vectors with unit norm and
> some flag to distinguish between coordinate systems. In this case
> transformations between different coordinate systems could be done using
> quaternions and are cheap (15 multiplications). So there are no reason to cache
> horizontal coordinates, they could be recalculated on the fly if desired.  Most
> of the projections also become cheaper since they don't involve trigonometry in
> this representation.
> 
> 
> This has been discussed on mail list before. You can search using "quaternion"
> keyword

Yeah, quaternions are certainly a good idea. Not sure Henry can fit it
into his time-line?

Regards
Akarsh