<br><br><div class="gmail_quote">2010/5/28 Henry de Valence <span dir="ltr"><<a href="mailto:hdevalence@gmail.com">hdevalence@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I've been trying to work out a way for KStars to be able to do both GL and<br>
non-GL painting. The problem is that in order to paint using GL, one must use<br>
a QGLWidget, but in order to paint using a normal QPainter (i.e., without GL),<br>
one needs to use a QWidget.</blockquote><div><br></div><div>I think it's possible to use QGLWidget for rendering with a QPainter like any other normal widget, since it inherits from QWidget. Take a look at here: <a href="http://doc.trolltech.com/4.6/qglwidget.html#details">http://doc.trolltech.com/4.6/qglwidget.html#details</a></div>
<div><br></div><div>>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Currently the SkyMap class inherits QWidget and<br>
uses that to paint. We can't make classes that inherit from SkyMap and one of<br>
(QWidget, QGLWidget), because SkyMap would still have to inherit QObject to<br>
get signals and slots, and multiple inheritance of QObject is not allowed.<br>
I've been working at separating all of the SkyMap code that is dependent on<br>
the inheritance from QWidget into another class for the past week, and even<br>
though the diff is so far over 2000 lines, I'm not even close to getting it to<br>
work, and it doesn't seem likely that I will be able to get it to work, at<br>
least within the time that I have -- since I have to actually implement GL<br>
painting, not just refactor things.<br>
<br>
When I was talking to Akarsh about this, he suggested the following:<br>
1. We use OpenGL as the only rendering engine.<br>
2. When dealing with "non-3D" graphics cards which don't have hardware support<br>
for fancy stuff, we cut down on effects and use OpenGL just as we'd use<br>
QPainter.<br>
<br>
One way to implement #2 would be to have KStars monitor its frame rate, and<br>
then automatically adjust the graphics quality so that it fell within a<br>
certain range (say, minimum 10 FPS, maximum 30 FPS): if the frame rate is too<br>
low, it would disable certain effects, and if the frame rate is too high, it<br>
would enable more expensive effects. Since I plan on putting drawing methods<br>
into a helper class (so that the drawing code is all in one place), it should<br>
be possible to have that helper class manage the level of graphical effects,<br>
taking into account performance and graphics card features.<br>
<br>
Does this seem like a reasonable approach?<br>
<font color="#888888"><br>
Henry de Valence<br>
_______________________________________________<br>
Kstars-devel mailing list<br>
<a href="mailto:Kstars-devel@kde.org">Kstars-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kstars-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kstars-devel</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Luiz Romário Santana Rios<br>