Dear team members,
Happy and successful year 2015 to all of you!
As you all surely know, our hopes from 2013/14 that ANGLE remedies us from
issues with outdated hardware by translating to any hardware that is
capable of running "any" kind of DirectX9 was too optimistic, so the older
OpenGL2.0 (and less) GLSL1.20 /DirectX ps_2 - capable hardware is out of
business except for using Mesa-based CPU rendering.
Qt5.4 seems to bring at least a chance to clean up this ugly OpenGL
version mess with up to 5 separate windows installers. However, some
effort seems required for that which goes way beyond my Qt knowledge (and
free time to learn it :-(
1) QtDeclarative has been deprecated a while ago and documentation links
are (deliberately I suppose) getting sparse. QGL... classes are
deprecated. We are still using them, but replacements have been made
available for most, if not all, functionality. Not having much experience
with these Qt window/widget classes does not help in finding correct
replacements.
2) Classes which need to draw with OpenGL gl... calls should be derived
from QOpenGLFunctions. The current situation is this #define nightmare in
StelOpenGL.hpp. What was the specific reason to do that and not follow the
documented and recommended path?
3) Qt5.4 brings a change to allow building binaries for the most widely
used platform that can locate and bind either native OpenGL, or OpenGL ES
(ANGLE) or fallback to software OpenGL (MESA) libraries on startup. This
however requires cleaning up issue (2) in the Qt way.
4) Just a note from trying my luck with compiling Qt5.4 on a Raspberry Pi.
The change from compile-time to runtime resolution of OpenGL functions
caused removal of a compile-time definition of QT_OPENGL_ES_2, which
likely breaks building at least core/external/glues_stel with an ANGLE or
other ES2 environment. I can build fine without a change in Windows with
Qt5.4/MinGW/OpenGL. Maybe for now you just need to add this #define
globally using
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DQT_OPENGL_ES_2")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DQT_OPENGL_ES_2")
in CMakeLists.txt when building an ANGLE-only binary, but in the longer
run, this is again linked to issue (2): all classes using gl... should be
derived from OpenGLFunctions (and initialized in their constructors), and
it should be enough to #include <qtopengl.h> instead of <GL/gl.h> etc.
I think therefore this current situation can be improved massively, but it
requires some effort. This must be the Next Big Thing for V0.14.
I tried my luck over the holidays but am stuck and had to see that I
cannot complete this by tonight. Is there anyone more fluent in /
knowledgeable about the current Qt GUI (i.e. QtQuick2,
QtOpenGLWidget/-Window, ...) classes able to do these necessary steps? I
leave my branch open as qt54-qtify, where I already replaced QtDeclarative
with QtQuick+QtQuickwidgets+QtQml, but got stuck with various class
changes, and I am of course not sure if my decisions of replacement
classes were the best. So maybe either start from here or anew from trunk.
I must currently cease work on this.
One further note on any possible replacement classes:
My Raspberry experiment indicated that Stellarium can be compiled on this
OpenGL ES2 embedded Linux system, but fails with a startup message:
EGLFS: OpenGL windows cannot be mixed with others.
What can be done or has to be avoided can hopefully be taken into account
when deciding on the new MainWindow pedigree (if we are interested in this
and related embedded Linux platforms):
http://comments.gmane.org/gmane.comp.lib.qt.user/11116
http://qt-project.org/forums/viewthread/44673
Good luck to all your efforts, and I hope for a good future for this
wonderful application.
Georg
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Stellarium-pubdevel mailing list
Stellarium-pubdevel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
