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

[David Powell]

option to eather enable or disable it  fine :)

although a note to say that if enabled it may have bugs by the option would
be recomended

i have to point out though that personaly i dont have generic openGL  on my
graphics card
openGL applications do work but are painfully slow dew to it beeing software
emulated

go for it ,, and  try not to break it too much :)


On Sat, Jan 1, 2011 at 10:31 AM, Akarsh Simha <akarshsimha at gmail.com> wrote:

> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJNHwJ3AAoJENfUWi5BqyX5G1MP/34/UbnVFKxkSD+6A/Y2QHuO
> 30Kqs16gL3Z/Osf5QFq8dwIULRigHwzPdJUiyBCSoOTi34faLUJBvZq2+IO5eVB+
> v8hNBrnho2o1jEs4+b6p15H3foT+iypkucx/G0zn17Igo4XqJS1KQ7wGLBmcdyWc
> mniQveOybJtP/woWuyjnryybAbuZtbYE3b9BoZLxcfda+//8SkoDOf7vZY1LquqP
> tI35fIfmjo/MM4gr8n5ZInSVgcVWKxMafDzPeBOhdMzKMXcc8OF0lmY6rSt5hZ4N
> cjt1SxoIlUivpLZ4KqRe7mHo00/Gsj/cGELaHB77zA4eC82rRe7WipEzEB3ZpRWA
> D6wmWlv3bviyWGAL7ysVgNISO4v0+1G39TgxCDWgA9hZ8gKZvNoChEwzhoEjm9DL
> kvQlqi76euOfjVZWpQOxUoPHLFbZlYVQbvQCBn4NzBz22H/6wKl8FG5gU0Ky4JIH
> +1nyrnqXSurMlok9Wik+augS1JeYOy1jnPik96by78s0BiObxs1A2tjl/R9XUt+z
> GKOzoZbef4mdkCITPsYB97wcEqhn2cNYeQisFtwKQxptLLXjB2gEwDvbzuCFgI4k
> z/oaIKcH4q1zhsY02hDizBp/UpCJ4t2QAdJW9cuNBpo/wxZ55/RnjsYY9CCm1HCB
> pjALl0nlQJkVv36eU1L5
> =TBWr
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kstars-devel/attachments/20110101/fd59eb4e/attachment.htm