[Kstars-devel] [urgent] To release OpenGL into KDE 4.6 or not -- need inputs.

[Akarsh Simha]

Hey

I need inputs (both from users and developers) here.

Since this mail is really long, I'm organizing it into
sections. Please read whatever is relevant to you and help me by
giving your opinions ASAP.

Context:
========

Trunk now has my solution to the OpenGL issue, and allows the user to
switch between OpenGL (which gives very dramatic improvements in
speed, but adds some bugs and regressions) and native QPainter
backends at run-time.

KDE SC 4.6 RC 2 is being tagged very shortly and trunk is frozen for
that on Jan 3rd! So we need to arrive at a decision as to whether to
get this in or not, into the release, by then.

The following are the code changes in summary (for developers):
===============================================================

+ SkyMap becomes a QGraphicsView

+ SkyMapQDraw is a QWidget and SkyMapGLDraw is a QGLWidget, and they
  both are made child widgets (of the viewport) of the
  QGraphicsView. These act as the drawing boards over which the sky
  map is drawn. All sky-map-related events are still handled by
  SkyMap (the QGraphicsView).

+ InfoBoxes are now a child widget of the SkyMapQDraw instead of the
  SkyMap. This is unclean, but a clean solution is not very
  straightforward, because the InfoBoxes widget (which acts like a
  manager for all the InfoBoxWidgets) starts capturing all events (and
  in the OpenGL case, starts painting its own background). My
  alternate solution involves doing away with this "manager" widget,
  but keeping it makes things so much more elegant. So it is hard,
  although we might have to eventually do away with it.

+ CMake detects OpenGL and enables this switching feature when GL is
  present


The following are the consequences, in summary (for packagers / users):
=======================================================================

FEATURES:

+ OpenGL is not required, but recommended, to build KStars.

+ If OpenGL is present, the user can switch to OpenGL rendering and
  enjoy smooth and speedy movements of the sky map.

  [Running at time step = 2 minutes, the frames/sec with OpenGL
  averages to about 16, whereas with native, it's about 7 on my
  machine. The QPainter version has visible coarseness in movement,
  while the OpenGL version has none]

REGRESSIONS:

+ In _all_ cases, the Info boxes flicker when being dragged around.

OPENGL SPECIFIC BUGS:

+ With OpenGL, Info boxes are not displayed at all

+ When using OpenGL, the Moon is not rendered at all (instead, a blank
  white square appears at high zoom, and a blue star appears at low
  zoom)

+ When using OpenGL, the Sun is rendered as a star when zoomed out.

(I'm sure there are a few more)


Summary of ugly hacks made (for developers):
============================================

These are the not-so-clean bits of code that are floating around.

+ We have two classes as friends of SkyMap, which is not really
  good. Some of the stuff should be handled entirely in the individual
  classes themselves.

+ It is not certain whether setting the widget as a child of the
  viewport of a QGV is the only way around the problem of being able
  to switch dynamically between two widgets. I remember carrying out a
  bunch of experiments and arriving at this solution, but I'm not
  sure. The documentation says that one should probably set it as the
  viewport widget itself, but I don't recall the result of trying
  this. In any case, this is the next thing I'm going to test.

+ Setting InfoBoxes as a child widget of the SkyMapQDraw is not a very
  good idea IMO, but that requires the least "big" changes at the
  moment.


Summary of ill-effects for users:
=================================

If you can tolerate some flicker while moving around those infoboxes
(if you ever move them), I expect you should be okay.

My take on this issue:
======================

I think we should release OpenGL rendering, and here are my arguments
in favor of this:

1. OpenGL is a big improvement, when it comes to painting speed. If
   you can tolerate some bugs, it's a better thing to use OpenGL
   because of speed. As a user, I would prefer the GL engine.

2. The code is bad, but isn't terrible IMHO. Considering that the
   documentation is sometimes unclear (at least to me), and various
   solutions suggested in the documentation are seemingly not working,
   I think we should accept this solution.

3. The maximum regression I could observe in my usage is the
   flickering of Infoboxes in QPainter mode.

4. Yes, the GL rendering is still incomplete. But we warn users that
   it is experimental. I don't see why one shouldn't benefit from
   speed just because of some shortcomings. Besides, you can switch to
   QPainter if a bug in GL is a significant usability issue.

5. Yes, there are two days for RC 2 release and that's too short for
   testing a major change. But I'd like to argue that KStars has not
   been tested anyway. Yes, we got one mail about the black screen
   here, but there is _no_ bug on the tracker that talks about KStars
   producing a black screen. So I'm presuming that any testing before
   release is testing that we do. I will try and promote testing in
   the next one week between RC2 and final tag by blogging, and will
   probably do some QA myself. We could even use a GCI task for
   testing.
   
   If there are critical bugs found in RC2, we could always revert to
   the last working version in time for the final tag.

6. Considering the rate of development in KStars, I fear we will end
   up releasing the same code for KDE SC 4.7 if we don't do it
   now. Why postpone a feature by 6 months?

7. By releasing the OpenGL version, we can get valuable feedback on it
   from our users.

An apology:
===========

I know I kinda said I'd take a shot at this issue, but I had to
postpone this till vacations, which is now, which unfortunately had to
be so close to the release. I admit I might've been able to get it
working a little earlier had I worked a little harder on this, but you
see work stretches to fill the time before the deadline :).

The Merger decision:
====================

Since Alexey has not been around for a while, I volunteer to take
charge of this issue, and I'm going to take this decision by majority
vote. At the moment, my vote is a +1. Harry gave me a -1 and Med gave
me a +1, but I guess the decisions will be more educated after this
mail. As of now, it stands at +1 overall and so I'm going to merge
OpenGL rendering before the 3rd if I get no more replies / opinions
regarding this.

Regards
Akarsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20110101/37c5ee01/attachment.sig