[Kstars-devel] OpenGL update / next steps / merging

[Henry de Valence]

Hi,

here's a brief update of the status of my branch, compared to when I started:
- Refactored all painting code into SkyPainter interface
- Put old painting code into SkyQPainter class
- Made an OpenGL implementation of the SkyPainter interface (SkyGLPainter)
- Refactored SkyLabeler to be able to replay label drawing (using QPicture)
- Refactored projection code out of the SkyMap and into a Projector interface

The GL backend runs about 10-15x faster, in my experience. There are a
few things that could be done to improve performance for the GL
backend even more, since 10-15x faster than "really slow" is still
"somewhat slow" and I hope to implement them when I have time.

Another thing that I think might help a great deal with the QPainter
backend is to add some method to the SkyPainter interface that allows
drawing the great-circle arc from point A to point B, and drawing the
(entire) great-circle that passes through points A and B. Then we can,
for instance, have it so that it breaks the great-circle arc into line
segments to target a certain line-length or max curvature per segment.

As for issues that remain in my branch and need fixing before the next
release, there are basically two (MAJOR) issues that are sort of tied
together:
a) One cannot currently switch between OpenGL and QPainter except at
compile-time
b) The infoboxes don't work.

Issue a) sounds really bad, and it is, but it's nothing to do with the
SkyPainter interface. Indeed, none of the skycomponents know which
backend they're using, and the "Export Sky Image" feature uses a
SkyQPainter to draw the sky, even when it's set to use the GL backend.
The two implementations of the SkyPainter are perfectly compatible.

The problem has to do with the SkyMap, and the fact that the SkyMap
both manages user interaction and the view of the sky AS WELL AS the
painting. If we want to use a SkyGLPainter, it is required that the
SkyMap inherit from a QGLWidget. If we want to use a SkyQPainter, we
may paint onto any paint device supported by QPainter -- including
QWidget and QGLWidget. But there's really no reason -- as far as I can
see -- to use the SkyQPainter if the SkyGLPainter is available (i.e.,
if we have hardware acceleration) and if it's not available, then
it'll be slower to use a QPainter on a QGLWidget than on a QWidget.

Using the SkyQPainter on a QGLWidget is a really sub-optimal solution
for anyone who doesn't have hardware-accelerated graphics. But we have
to pick which class SkyMap inherits from at compile-time, and so it's
not really workable to do what is currently done in my branch: have
SkyMap inherit from one of QWidget, QGLWidget based on a compiler
#define.

What *should* be done to fix this is to seperate the widget that is
being drawn on from the SkyMap's other purposes, but I am not sure of
the best way to do this. Stellarium uses a graphics view, but I don't
think looking at how they do it will be very helpful to us since they
don't care about non-GL stuff, and so don't need to solve out problem
anyways, and also they need GV to do their own reimplementation of a
window system.

I personally don't know much about graphicsview or what the best way
to proceed with that might be, so any advice would be appreciated.

The issue with the infoboxes has to do with the fact that putting
QWidgets inside a QGLWidget is not supported as far as I can tell. If
we used graphicsview we might be able to make the info boxes graphics
items; otherwise we'd need to do something else.

Anyways, other than that issue having to do with the fact that the
SkyMap wasn't meant to have more than one painting method, compounded
by the fact that the class is so large that it's incredibly difficult
to change, there don't seem to be many major issues with my branch --
though of course there will be bugs and rough edges that people find
in testing.

Shall I merge my branch with trunk, using the GL painter iff GL is
found, until we get a good solution to the above issue?

Henry de Valence

P.S. The GL backend and the Projector implementation use Eigen to do
vector stuff, because it makes dealing with vectors much easier, and
without the overhead of the Qt classes. Eigen is template-based,
however, so there is no run-time dependency, only a compile-time one.
If people don't like it, then we can write our own vector classes, but
that seems like a bad  idea.