[Kstars-devel] Plans for threading in KStars

[Alexey Khudyakov]

On 30.10.2011 11:09, Akarsh Simha wrote:
> 1. Fork in StarComponent::draw() at starcomponent.cpp:284, before
>     while( region.hasNext() )
>
> 2. Each StarObject has a QMutex in it.
>
> 3. Computation thread calls various computational routines (which
>     acquire a lock on the StarObject and update the coordinates)
>
> 4. Draw thread checks the updateID on the star and if it is not the
>     drawID, it just waits. When updateID becomes drawID, it acquires a
>     mutex on the star and executes drawPointSource() to draw the star.
>
> Further TODO: Keep computing and caching future values of positions.

I'm not sure that it's possible to parallelize drawing, in particular 
OpenGL. AFAIK it uses some thread-local storage so all calls must be 
made from same thread (At least some implementations have such 
requirements).

It's quite possible that drawing couldn't be parallelized anyway. Since 
drawing primitives will be executed sequentially eliminating all 
possible benefits from threading.

Also how many threads will we get? It sounds they could count in 
thousands which shall hurt performance.

Overall I'm not sure that multithreading is good idea for KStars at the 
moment. We got quite a few crash reports lately and it takes time to fix 
them. Personally I don't like adding threading bugs (and we'll create 
some) which are harder to trace.

Did anyone profile KStars with QPainter and OpenGL backend? What are 
current bottlenecks? IIRC coordinate grid and constellation lines at low 
zoom were slowest of all.