From: Georg Z. <geo...@un...> - 2014-02-14 15:28:42
|
Dear Fabien! I also think that likely everything that's in trunk currently can run in OpenGLES2.0 if that is almost equivalent to OpenGL2.1. However, some of the things that still await integration in scenery3d are based on OpenGL3.2. That 0.12 renderer class update prevented integration, but the return of the previous API for the 0.13 series made me hope again. Meanwhile also newer Intel HD systems support OpenGL4 (at least per specs), so scenery3d should also run on them, if I ever get around successfully calling initializeOpenGLFunctions() and subsequently reactivating Andrei's code. (Unfortunately Andrei is no longer available.) Alex tried to compile Stellarium with MSVC/Qt/ANGLE a few weeks ago, it did not work (cannot remember the details, but I think mostly OpenGL(ES) related errors). I have not tried myself, but a working Cmake/MSVC2012-free/Qt-Angle building path would be a useful starting point to test and adapt to an optional OpenGLES2.0 build. (There is no Qt-Angle for MinGW, and I wouldn't want to have to build it! I only have my Atom 450 netbook to test that, and building Stellarium-MinGW for Qt4.8 took ages, that indicates at least overnight for Qt(?), and that is reportedly difficult), so it's no fun developing with that. Not sure if its already possible to have Angle and non-Angle installed at the same time on a more powerful system, I remember having read it's not possible with Qt5.0. So, if OpenGLES2.0 is just a few #ifdefs apart from "real" OpenGL2.1, there may be two Windows versions: Angle/OpenGLES2 as successor of what used to be "fallback mode" to run on legacy hardware (no problem not to have scenery3d on a travel/mobile-telescope netbook or some 2006 vintage PC), and on the other hand an OpenGL version for systems with OpenGL2.1 and better drivers, where add-ons and plugins with higher OpenGL functions may then easier mix. However, somebody please hit me with a working HOWTO Qt5/OpenGL(ES) tutorial that applies to our class infrastructure. On GUI changes: Some things can be rearranged, but most GUI changes in the last 2 years were also a question of available space. My candidate for relocation would be the projection setting in the "Marks" tab, or generally the first two tabs could be rearranged. I think esp the DeltaT model switch (in the advanced settings anyway) is a unique feature and very useful, if only for a handful of scientists. Maybe a caution like "use only if you know what you are doing" should be added if the default model is not in use, or a tick "Expert Mode" added that deactivates the DeltaT panel if not active? Or add a new tab "Expert settings" to the F2 menu? (This could actually go on a tab together with the Planetarium settings, which are also definitely not for everybody.) Kind regards, Georg On Fr, 14.02.2014, 14:21, Fabien Chéreau wrote: > Hi Georg, > thanks for the detailed email. > > In term of code, stellarium needs only quite limited opengl features. > OpenGL ES2.0 should be enough, or OpenGL 2.1 (on desktop) should also be > enough. However, on windows, we should only use the ANGLE version of Qt, > from Qt website: > "For QtQuick > <https://qt-project.org/doc/qt-5.1/qtquick/qtquick-module.html> > 2.0 > to work, a graphics driver that provides OpenGL 2.1 or higher is required. > The Windows default driver provides only OpenGL 1.1, which is not > sufficient. To work around this limitation, Qt now includes a version of > the ANGLE <http://code.google.com/p/angleproject/> project which is used > by > default. ANGLE implements the OpenGL ES 2.0 API on top of DirectX 9. ANGLE > requires that the DirectX SDK is installed when building Qt." > > -> So in theory using Qt5 ANGLE version, the requirement on windows should > be DirectX 9c, and on Mac/Linux OpenGL 2.1 > What kind of advanced features would you like to use in the code? > > For coming versions of Stellarium, we should try to stop using > GraphicsView, i.e. re-implement the base button bars GUI in QtQuick2, and > try to preserve our current dialogs code using code like the > createWindowContainer > stuff mentioned by Guillaume. > We should also start to think about a roadmap for moving all GUI to QML. > For the basic GUI it should actually not be that difficult, I'm not too > sure about the GUI in plugins. Maybe it would be a good opportunity to > re-think and simplify the main GUI which is getting a bit too complicated: > for example choosing the delta T model should definitely not be something > that a regular user see in the main GUI. > > Fabien > > > > > > On Thu, Feb 13, 2014 at 11:36 AM, Georg Zotti > <geo...@un...>wrote: > >> Dear Guillaume! >> >> First, thank you for looking into this. This is a major architectural >> change, so I can imagine it's not simple. >> >> When I wrote the bug report, I tried alpha5 (?) on an Intel PC that >> should >> support OpenGL2.1. I have no build environment on this and cannot spend >> much time on Stellarium there. It complains in the logfile about >> unresolved OpenGL functions, and in night mode displays a big dark-red >> rectangle in the lower left corner (limited by the extents of the >> sliding >> button bars). I also tried with the Mesa library, here it worked, but of >> course quite slow (it is a dual-core2 though, so still not too bad >> (2009?)). That means, once again it's mostly an Intel driver problem, >> but >> that PC is not so old and should support current Qt, and may represent a >> considerable fraction of users' PCs. I think I have also reproduced the >> same issue on an i3 notebook (HD3000 graphics). Maybe also that Intel >> driver is just pickier about having to use initializeOpenGLfunctions(?) >> or >> such, but for OpenGL2.1 I had thought it is not necessary? Apparently >> this >> call gives different results on Win and Linux, my scenery3d branch seems >> to initialize OK on Linux (Alex reported) and always failed on my >> Win7/NVidia system. >> >> I can also only guess when QtDeclarative will be removed from Qt, but I >> can imagine that Qt devs will not invest much time into keeping it alive >> when they talk so much more about, and want devs to convert to use, >> QtQuick2. So my thoughts were that all things documented in Qt work only >> reliably with the newer classes. >> >> Else, on the cheap-hardware base, I don't know where we should go: Shall >> Stellarium rather be converted to work on OpenGL-ES2.0 with no higher >> OpenGL functionality, or can we mix development that involves higher >> GPUs' >> OpenGL3.2 or better with just a few #ifdefs? I am afraid I don't know >> the >> programming details and differences concerning OpenGLES. Given the >> enormous popularity of Stellarium from schools to world-class >> observatories (wow!), it would be nice to have our application in basic >> functionality available on all Qt platforms: Androids, netbooks (using >> the >> Angle crutch) and toy computers (Raspberries etc.), but advanced >> versions >> available in plugins that would then work only on powerful hardware, if >> that is possible. Cheap/old hardware with Mesa (esp. single-core CPUs) >> is >> too slow. Better old hardware (like that Intel used above) can be kicked >> to work with Mesa. If only one type of OpenGL is possible, I strongly >> vote >> for higher quality thingies (dropping hopes in OpenGL1.4 hardware and >> Angle translating OpenGLES2.0 to DirectX9c), and would like to see a >> working example of initializeOpenGLfunctions() on Windows... >> >> Best regards, and good luck and rapid success with trials, >> Georg >> >> >> On Do, 13.02.2014, 09:16, Guillaume Chéreau wrote: >> > OK, I did some tests. So far I have no luck using >> > createWindowContainer: each time the container hides any other widget >> > no matter how I try. This is not good because for stellarium we need >> > to show first the qml view, and then the normal widgets (for the >> > settings windows) on top of it. >> > >> > I will try to ask the Qt dev how to achieve that. >> > >> > Meanwhile what exactly is the problem with the current qml fragment >> > shader? For me it seems to work on windows, linux and OSX. Do we >> > have more info about when QDeclarativeView will be deprecated? One >> > thing I could do is start to work on the qml UI using QtQuick 1.0 in a >> > branch, then later switch it to QtQuick 2.0. >> > >> > gui >> > >> > On Thu, Feb 13, 2014 at 11:41 AM, Guillaume Chéreau >> > <gui...@gm...> wrote: >> >> On Sun, Jan 12, 2014 at 7:25 PM, Georg Zotti >> <geo...@un...> >> >> wrote: >> >>> I had the same fear for weeks now that the deprecation of >> QtDeclarative >> >>> will sooner than later hit us. Is anybody working on this? >> >>> Fabien, Guillaume? Anybody else with deep enough insight into Qt? >> What >> >>> has >> >>> to be done, where? >> >> >> >> I had a look at this yesterday. The problem is that currently Qt >> does >> >> not allow to mix QtQuick 2.0 and widgets very well. There is >> >> QWidget::createWindowContainer() that might help : >> >> >> >> >> https://blog.qt.digia.com/blog/2013/02/19/introducing-qwidgetcreatewindowcontainer/ >> >> >> >> With this we could maybe have the sky + the basic UI (bottom and left >> >> bars) written in qml (with QtQuick 2.0), and keep the settings >> windows >> >> as they are now. >> >> >> >> An other way would be to rewrite the entire UI in qml, but this would >> >> take a lot of effort. >> >> >> >> Anyway I am going to make more tests to see how we can do the >> >> transition. I think having the bottom and left bars in qml would be >> >> an improvement to the code anyway. >> >> >> >> Regards, >> >> >> >> guillaume >> >> >> >>> >> >>> Still very much hoping for a "Yes, I do", >> >>> >> >>> Best regards, Georg >> >>> >> >>> >> >>> On Fr, 10.01.2014, 19:23, Reaves, Timothy wrote: >> >>>> Until this is completed, Stellarium is now completely broken. >> >>>> >> >>>> The shaders the app uses require QtQuick 2.0 now, as that is where >> the >> >>>> labs >> >>>> stuff was moved. When moving to QtQuick 2.0, we need to replace >> >>>> QDeclarativeView with QQuickView. >> >>>> >> >>>>>From the docs: "When porting from QDeclarativeView to QQuickView, >> note >> >>>>> that >> >>>> QDeclarativeItem inherited from QGraphicsView. In contrast, >> QQuickView >> >>>> inherits from QQuickWindow and uses the QWindow infrastructure >> >>>> introduced >> >>>> in Qt 5; any QGraphicsView-specific functionality is no longer >> >>>> available." >> >>>> >> >>>> This is some major work around the windowing code; dialogs, >> widgets, >> >>>> menus, >> >>>> etc. >> >>>> >> >> >> >> >> ------------------------------------------------------------------------------ >> Android apps run on BlackBerry 10 >> Introducing the new BlackBerry 10.2.1 Runtime for Android apps. >> Now with support for Jelly Bean, Bluetooth, Mapview and more. >> Get your Android app in front of a whole new audience. Start now. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk >> _______________________________________________ >> Stellarium-pubdevel mailing list >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > -- Dipl.-Ing. Dr. Georg Zotti Ludwig Boltzmann Institute for Archaeological Prospection and Virtual Archaeology (LBI ArchPro) Hohe Warte 38 A-1190 Wien |