[Kstars-devel] Fwd: SoC progress

[Alexey Khudyakov]

Forgot to CC mailing list...

---------- Forwarded message ----------

Hi!

On Thu, Jul 15, 2010 at 8:07 AM, Henry de Valence <hdevalence at gmail.com> wrote:
> 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.
>
One possibility is to add child widget to skymap which is subclass either of
QWigdet or QGLWidget. All drawing could be performed on them and child widget
could be removed and recreated at run-time.

> 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.
>
Everything sounds sensible. SkyMap is surely overly bloated. And it's really
which should be done. Maybe I'll have more to say after I read the code.

Currently I try to cut down SkyMap class, to move away as much methods as
possible. Refracion corrections are moved into SkyPoint class. Also dms
couldn't be implicitly constructed from doubles now. Also for all methods
which has two variants (accept double and dms) double-based one is removed.
This is to simplify interface and remove possible ambiguity.

I think it's good momemnt to merge with trunk.

> 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.
>
One of my findings is that drawing of constellation borders at low zoom takes
about half of drawing time. With QPainter of course.

If you want to have around 30FPS then calculation projections would be a
bottleneck. With QPainter based code it is not. Projections take only small part
of 1s drawing.