[Kstars-devel] KStars & OpenGL

[Alexey Khudyakov]

On Fri, 28 May 2010 03:31:55 -0400
Henry de Valence <hdevalence at gmail.com> wrote:

> I've been trying to work out a way for KStars to be able to do both GL and 
> non-GL painting. The problem is that in order to paint using GL, one must use 
> a QGLWidget, but in order to paint using a normal QPainter (i.e., without GL), 
> one needs to use a QWidget. Currently the SkyMap class inherits QWidget and 
> uses that to paint. We can't make classes that inherit from SkyMap and one of 
> (QWidget, QGLWidget), because SkyMap would still have to inherit QObject to 
> get signals and slots, and multiple inheritance of QObject is not allowed. 
> I've been working at separating all of the SkyMap code that is dependent on 
> the inheritance from QWidget into another class for the past week, and even 
> though the diff is so far over 2000 lines, I'm not even close to getting it to 
> work, and it doesn't seem likely that I will be able to get it to work, at 
> least within the time that I have -- since I have to actually implement GL 
> painting, not just refactor things.
> 
> When I was talking to Akarsh about this, he suggested the following:
> 1. We use OpenGL as the only rendering engine.
> 2. When dealing with "non-3D" graphics cards which don't have hardware support 
> for fancy stuff, we cut down on effects and use OpenGL just as we'd use 
> QPainter.
> 
IMHO right way is to have both normal Qt and OpenGL based rendering. AFAIK
without hardware acceleration OpenGL is dead slow.  Also there might be no
OpenGL at all. 3D on linux isn't in very good shape. For many people thing may
just stop working. One more point: what about printing star charts?

>> This class is not part of the Qt GUI Framework Edition.

>> QGLWidget provides functionality for displaying OpenGL graphics integrated
>> into a Qt application. It is very simple to use. You inherit from it and use
>> the subclass like any other QWidget, except that you have the choice between
>> using QPainter and standard OpenGL rendering commands.

Above are quotes from Qt documentation. Maybe you could just draw on
QGLWidget using QPainter? This will make thing much easier.


> One way to implement #2 would be to have KStars monitor its frame rate, and 
> then automatically adjust the graphics quality so that it fell within a 
> certain range (say, minimum 10 FPS, maximum 30 FPS): if the frame rate is too 
> low, it would disable certain effects, and if the frame rate is too high, it 
> would enable more expensive effects. Since I plan on putting drawing methods 
> into a helper class (so that the drawing code is all in one place), it should 
> be possible to have that helper class manage the level of graphical effects, 
> taking into account performance and graphics card features.
> 
> Does this seem like a reasonable approach?
> 
This seems somewhat overengineered to me. It's difficult to implement
properly. There are use case when want high quality and low frame rates are
OK. This behavior might be surprising. Maybe it would be better to start with
straightforward implementation and add such feature later and only if it would
be really needed?

-- 
Alexey Khudyakov <alexey.skladnoy at gmail.com>