[Kstars-devel] SoC progress

[Henry de Valence]

Hey, I realized that up to now I'd mostly been talking with Akarsh and not 
with the mailing list or with planetkde. As of now I have an OpenGL KStars 
that is mostly up to par with the QPainter backend in terms of functionality 
-- for pictures and a bit more detail see the post here: [0]

What I did was first refactor all of the drawing code in the draw() functions 
of the components so that it did not use a QPainter. Instead, it now uses a 
SkyPainter, which is an abstract class that provides an interface for painting 
things onto the sky. Its methods deal with only *unprojected* items; the 
actual projection is done internally, and it's different for each one: the 
QPainter backend uses QPointFs; the GL backend uses Eigen::Vector2fs (cf. 
[1]).

Then, I implemented a SkyGLPainter class that does the actual GL painting. It 
doesn't actually draw things right away; it first loads the vertex and color 
data into buffers and then flushes them when they are full, or when the painter 
is told to finish. The size and implementation of the buffers could perhaps use 
some tuning. 

There are a few problems that I need to solve. The first is to do with the 
SkyMap. The suggestion earlier was to use a QGLWidget and paint on it with a 
QPainter if we are not to be using GL. This is IMO a bad idea.The main reason 
why is that QPainter uses OpenGL when painting on a QGLWidget, so drawing with 
a QPainter on a QGLWidget may be even slower than just normal drawing if the 
gfx card is poor.

Currently I temporarily disabled the QPainter backend and didn't bother with 
any overpainting stuff because it's incredibly finicky and I couldn't get it to 
work after trying for a week. I need a way to draw onto a QWidget in one case 
and a QGLWidget in the other, and I need to be able to switch at runtime.

I think that the 'best' solution would be to break up the SkyMap class and 
pull the painting out of it, but I am not sure whether this is really doable. 
If it is doable, would, say, an Observer class (holds location, time, what is 
being looked at -- e.g. viewport params), a Projector interface with 
subclasses to do the actual projection (e.g. StereographicProjection etc -- 
this is how things are done in Stellarium and Marble), classes to render with 
a QWidget/QGLWidget, and glue everything together in the KStars class? I am 
not sure what is best. Suggestions would be appreciated.

Also, I am wondering whether the main bottlenecks of KStars performance are 
known. I ask because I notice that if I don't actually draw the buffers, the 
performance is not really improved, which would indicate to me that the main 
costs are not actually in the drawing. I haven't actually used a profiler yet 
so I can't really give any facts.

Harry de Valence

P.S. Sorry for the long time without posting to the ML.

[0] http://hdevalence.wordpress.com/2010/07/14/kstars-soc-update/
[1] http://websvn.kde.org/?view=revision&revision=1141433