Dear Guillaume, thanks for clearing things up a bit. More answers below.
On Mo, 12.01.2015, 03:04, Guillaume Chereau wrote: > Hello Georg, happy new year everyone! > > > Currently we still need QtDeclarative as it is the only way -that I am > aware of- to embed QWidgets into an opengl view. Last time I checked, > it was impossible to do it using a QQuickView. Qt5.4 comes with QOpenGLWidget. Does that help? >> 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? > > The reason is because QOpenGLFunctions methods are not const, which > makes it impossible to call them from any const method when inheriting > from it (see https://bugreports.qt.io/browse/QTBUG-39095). That's why > we use the more verbose > QOpenGLContext::currentContext()->functions()->glXXX way on Windows. I > put the macro so that we don't have to type the whole thing for each > opengl call. So, would the "official" Qt way be to change those callers to non-const as well? Would that cost performance, or is it just a nuisance to change existing code? (Sorry to ask seemingly stupid questions, but C++ was not my "native" language. ) >> 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. > > Yes, I just committed a small fix to allow compilation on Windows with > Qt 5.4. Basically the problem is that since Qt 5.4 do not link with any > opengl implementation, the only way to call opengl function is through > QOpenGLFunctions. Qt also now make it simpler by having all the OpenGL > functions accessible as methods of QOpenGLFunctions, previously they had > this annoying idea of only reimplementing the problematic functions. So > at least with Qt 5.4 there is a clear unique way of doing opengl: all > the calls should be made from QOpenGLFunctions. Yes, that's what they wrote in the Qt blogs. > Also when downloading Qt 5.4, I only consider the 'normal' version, not > the one with 'opengl' prefix. The normal Qt 5.4 windows version is > better since it includes both OpenGL and ANGLE libraries. Yes, this version definitely should be preferred now as it builds the "unified" OpenGL/ANGLE/MESA version and should be able to sort out the best way on application start (if properly initialized). The MinGW version only builds OpenGL. > > I had a very quick look at your branch, but it failed to compile. Yes, written in my last commit message. :-( I am afraid it was not the best attempt to use here, it turned out to involve many more classes than anticipated. (StelDialogs, etc.) Some replacement classes lack functionality of the original classes, or I did not find the right replacements. > I > still think currently it is not possible to get ride of QtDeclarative > because that is the only way Qt allows to put QWidgets on top of an > opengl view. Of course one solution would be to rewrite the whole GUI > in qml (is that what you try to do in your branch?), but this would be a > massive work, so I am not sure if it is the right thing to do. No, I only upgraded the (simple enough for me) qml file that includes the basic elements. Else, I just tried to activate the proper replacements Qt classes, but got stuck with suddenly too many changed classes. > Then, maybe I am wrong and there is a way to embed QWidgets into an > OpenGL windows without using QtDeclarative (for example by putting a > qwidget inside qml view?) If we find a way to do that we could simplify > the code a lot without having to rewrite any of the UI code. I hope the new QOpenGLWidget is what you need. > >> 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. > > Unfortunately I am not familiar with the Raspberry. Do simple Qt > + OpenGL ES 2 examples work on it? Yes, the cube example works great, even in FullHD. So the GPU is likely OK, now it's a matter of whether the CPU is able to provide at least a few fps. But the EGLFS issue is something I have no idea about. Just hope that the newer classes might solve it. The RaspPi as potentially useful platform is also new for me, and I have just started reading terms like EGLFS, Wayland, etc. Maybe Wayland is a solution here, but I did not dive deep enough here. So far I had only used the RasPi as media player, but originally it's an educational computer, and I simply like the prospect of having a super-cheap 2W-computer running Stellarium... Some related info: http://qt-project.org/wiki/Native_Build_of_Qt5_on_a_Raspberry_Pi and the background behind problems with EGLFS http://doc-snapshot.qt-project.org/qt5-dev/embedded-linux.html#eglfs http://comments.gmane.org/gmane.comp.lib.qt.user/11116 http://qt-project.org/forums/viewthread/44673 Best regards, Georg ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Stellarium-pubdevel mailing list Stellarium-pubdevel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
