[Kstars-devel] Fwd: SoC progress

[Henry de Valence]

On July 17, 2010 12:07:46 pm Alexey Khudyakov wrote:
> 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.

Yes, this is what I'd like to do.

> 
> > 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.

I'd rather not just yet; there are a few things that need fixing before the GL 
painting system is up-to-par. Specifically, the horizon is disabled, and the 
labels don't work. But I should be able to fix up those items.

> > 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.

I did some profiling and found two major bottlenecks: first, the code in 
SkyGLPainter::addItem() -- but this gets *much*, *much* faster if you compile 
in release mode, because it uses Eigen, and Eigen does magical optimization. I 
heard that the Mandelbrot wallpaper runs up to 100x faster compiled in release 
mode, for instance. I found that changing from debug to release modes doubled 
the speed. The other bottleneck is the projection. Perhaps moving projection 
code into seperate subclasses will allow for optimization?

It would also be nice to have a method that operated on arrays, for instance, 
so one could project, say, 1024 points at a time.

Currently on my machine I can get between 15 and 20 FPS. There is still room 
for improvement, I think.

One other thing: the Milky way. To get the milky way to work properly with the 
GL painter we will have to change the data, because it has non-convex 
polygons, or use a tesselator function in GLU or something. But I'd rather use 
a texture in the GL painter. The problem then is how to deal with this 
difference. Would it be better to have the Milky Way try to see which painter 
it is using (i.e., dynamic_cast) and draw differently? This seems sort of ugly, 
but I am not sure how else to do it. Any suggestions would be appreciated.

Henry de Valence