option to eather enable or disable it fine :)<br><br>although a note to say that if enabled it may have bugs by the option would be recomended<br><br>i have to point out though that personaly i dont have generic openGL on my graphics card <br>
openGL applications do work but are painfully slow dew to it beeing software emulated <br><br>go for it ,, and try not to break it too much :)<br><br><br><div class="gmail_quote">On Sat, Jan 1, 2011 at 10:31 AM, Akarsh Simha <span dir="ltr"><<a href="mailto:akarshsimha@gmail.com">akarshsimha@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hey<br>
<br>
I need inputs (both from users and developers) here.<br>
<br>
Since this mail is really long, I'm organizing it into<br>
sections. Please read whatever is relevant to you and help me by<br>
giving your opinions ASAP.<br>
<br>
Context:<br>
========<br>
<br>
Trunk now has my solution to the OpenGL issue, and allows the user to<br>
switch between OpenGL (which gives very dramatic improvements in<br>
speed, but adds some bugs and regressions) and native QPainter<br>
backends at run-time.<br>
<br>
KDE SC 4.6 RC 2 is being tagged very shortly and trunk is frozen for<br>
that on Jan 3rd! So we need to arrive at a decision as to whether to<br>
get this in or not, into the release, by then.<br>
<br>
The following are the code changes in summary (for developers):<br>
===============================================================<br>
<br>
+ SkyMap becomes a QGraphicsView<br>
<br>
+ SkyMapQDraw is a QWidget and SkyMapGLDraw is a QGLWidget, and they<br>
both are made child widgets (of the viewport) of the<br>
QGraphicsView. These act as the drawing boards over which the sky<br>
map is drawn. All sky-map-related events are still handled by<br>
SkyMap (the QGraphicsView).<br>
<br>
+ InfoBoxes are now a child widget of the SkyMapQDraw instead of the<br>
SkyMap. This is unclean, but a clean solution is not very<br>
straightforward, because the InfoBoxes widget (which acts like a<br>
manager for all the InfoBoxWidgets) starts capturing all events (and<br>
in the OpenGL case, starts painting its own background). My<br>
alternate solution involves doing away with this "manager" widget,<br>
but keeping it makes things so much more elegant. So it is hard,<br>
although we might have to eventually do away with it.<br>
<br>
+ CMake detects OpenGL and enables this switching feature when GL is<br>
present<br>
<br>
<br>
The following are the consequences, in summary (for packagers / users):<br>
=======================================================================<br>
<br>
FEATURES:<br>
<br>
+ OpenGL is not required, but recommended, to build KStars.<br>
<br>
+ If OpenGL is present, the user can switch to OpenGL rendering and<br>
enjoy smooth and speedy movements of the sky map.<br>
<br>
[Running at time step = 2 minutes, the frames/sec with OpenGL<br>
averages to about 16, whereas with native, it's about 7 on my<br>
machine. The QPainter version has visible coarseness in movement,<br>
while the OpenGL version has none]<br>
<br>
REGRESSIONS:<br>
<br>
+ In _all_ cases, the Info boxes flicker when being dragged around.<br>
<br>
OPENGL SPECIFIC BUGS:<br>
<br>
+ With OpenGL, Info boxes are not displayed at all<br>
<br>
+ When using OpenGL, the Moon is not rendered at all (instead, a blank<br>
white square appears at high zoom, and a blue star appears at low<br>
zoom)<br>
<br>
+ When using OpenGL, the Sun is rendered as a star when zoomed out.<br>
<br>
(I'm sure there are a few more)<br>
<br>
<br>
Summary of ugly hacks made (for developers):<br>
============================================<br>
<br>
These are the not-so-clean bits of code that are floating around.<br>
<br>
+ We have two classes as friends of SkyMap, which is not really<br>
good. Some of the stuff should be handled entirely in the individual<br>
classes themselves.<br>
<br>
+ It is not certain whether setting the widget as a child of the<br>
viewport of a QGV is the only way around the problem of being able<br>
to switch dynamically between two widgets. I remember carrying out a<br>
bunch of experiments and arriving at this solution, but I'm not<br>
sure. The documentation says that one should probably set it as the<br>
viewport widget itself, but I don't recall the result of trying<br>
this. In any case, this is the next thing I'm going to test.<br>
<br>
+ Setting InfoBoxes as a child widget of the SkyMapQDraw is not a very<br>
good idea IMO, but that requires the least "big" changes at the<br>
moment.<br>
<br>
<br>
Summary of ill-effects for users:<br>
=================================<br>
<br>
If you can tolerate some flicker while moving around those infoboxes<br>
(if you ever move them), I expect you should be okay.<br>
<br>
My take on this issue:<br>
======================<br>
<br>
I think we should release OpenGL rendering, and here are my arguments<br>
in favor of this:<br>
<br>
1. OpenGL is a big improvement, when it comes to painting speed. If<br>
you can tolerate some bugs, it's a better thing to use OpenGL<br>
because of speed. As a user, I would prefer the GL engine.<br>
<br>
2. The code is bad, but isn't terrible IMHO. Considering that the<br>
documentation is sometimes unclear (at least to me), and various<br>
solutions suggested in the documentation are seemingly not working,<br>
I think we should accept this solution.<br>
<br>
3. The maximum regression I could observe in my usage is the<br>
flickering of Infoboxes in QPainter mode.<br>
<br>
4. Yes, the GL rendering is still incomplete. But we warn users that<br>
it is experimental. I don't see why one shouldn't benefit from<br>
speed just because of some shortcomings. Besides, you can switch to<br>
QPainter if a bug in GL is a significant usability issue.<br>
<br>
5. Yes, there are two days for RC 2 release and that's too short for<br>
testing a major change. But I'd like to argue that KStars has not<br>
been tested anyway. Yes, we got one mail about the black screen<br>
here, but there is _no_ bug on the tracker that talks about KStars<br>
producing a black screen. So I'm presuming that any testing before<br>
release is testing that we do. I will try and promote testing in<br>
the next one week between RC2 and final tag by blogging, and will<br>
probably do some QA myself. We could even use a GCI task for<br>
testing.<br>
<br>
If there are critical bugs found in RC2, we could always revert to<br>
the last working version in time for the final tag.<br>
<br>
6. Considering the rate of development in KStars, I fear we will end<br>
up releasing the same code for KDE SC 4.7 if we don't do it<br>
now. Why postpone a feature by 6 months?<br>
<br>
7. By releasing the OpenGL version, we can get valuable feedback on it<br>
from our users.<br>
<br>
An apology:<br>
===========<br>
<br>
I know I kinda said I'd take a shot at this issue, but I had to<br>
postpone this till vacations, which is now, which unfortunately had to<br>
be so close to the release. I admit I might've been able to get it<br>
working a little earlier had I worked a little harder on this, but you<br>
see work stretches to fill the time before the deadline :).<br>
<br>
The Merger decision:<br>
====================<br>
<br>
Since Alexey has not been around for a while, I volunteer to take<br>
charge of this issue, and I'm going to take this decision by majority<br>
vote. At the moment, my vote is a +1. Harry gave me a -1 and Med gave<br>
me a +1, but I guess the decisions will be more educated after this<br>
mail. As of now, it stands at +1 overall and so I'm going to merge<br>
OpenGL rendering before the 3rd if I get no more replies / opinions<br>
regarding this.<br>
<br>
Regards<br>
<font color="#888888">Akarsh<br>
</font><br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
<br>
iQIcBAEBCAAGBQJNHwJ3AAoJENfUWi5BqyX5G1MP/34/UbnVFKxkSD+6A/Y2QHuO<br>
30Kqs16gL3Z/Osf5QFq8dwIULRigHwzPdJUiyBCSoOTi34faLUJBvZq2+IO5eVB+<br>
v8hNBrnho2o1jEs4+b6p15H3foT+iypkucx/G0zn17Igo4XqJS1KQ7wGLBmcdyWc<br>
mniQveOybJtP/woWuyjnryybAbuZtbYE3b9BoZLxcfda+//8SkoDOf7vZY1LquqP<br>
tI35fIfmjo/MM4gr8n5ZInSVgcVWKxMafDzPeBOhdMzKMXcc8OF0lmY6rSt5hZ4N<br>
cjt1SxoIlUivpLZ4KqRe7mHo00/Gsj/cGELaHB77zA4eC82rRe7WipEzEB3ZpRWA<br>
D6wmWlv3bviyWGAL7ysVgNISO4v0+1G39TgxCDWgA9hZ8gKZvNoChEwzhoEjm9DL<br>
kvQlqi76euOfjVZWpQOxUoPHLFbZlYVQbvQCBn4NzBz22H/6wKl8FG5gU0Ky4JIH<br>
+1nyrnqXSurMlok9Wik+augS1JeYOy1jnPik96by78s0BiObxs1A2tjl/R9XUt+z<br>
GKOzoZbef4mdkCITPsYB97wcEqhn2cNYeQisFtwKQxptLLXjB2gEwDvbzuCFgI4k<br>
z/oaIKcH4q1zhsY02hDizBp/UpCJ4t2QAdJW9cuNBpo/wxZ55/RnjsYY9CCm1HCB<br>
pjALl0nlQJkVv36eU1L5<br>
=TBWr<br>
-----END PGP SIGNATURE-----<br>
<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>
<br></blockquote></div><br>