[Interest] Help!! app qt4 upgrade to qt5 for wayland on tizen ivi, can't get the QDialog's window handle which can cast to EGLNativeWindowType

[Till Oliver Knoll]

Am 08.08.2014 um 10:25 schrieb "Steve (YiLiang) Zhou" <szhou at telecomsys.com>:

> Thanks Giulio,
> Our app has an render thread which use opengl api to draw something like map on eglsurface.
> So I was thinking about to use  a QGLWidget to render it , just call glwidget->makeCurrent() when the render thread ready to draw a frame.
> I don't need to embed a QGLWidget to another waylandwindow, just new a QGLWidget which is a child of our app mainwindow(qt mainwindow).
> I tried to do it ,but got errors like this: "Cannot make QOpenGLContext current in a different thread" and crash .
> Is my solution theoretically make sense?

Hi,
 
I just jumped into this discussion and grabbed some rough understanding of what you’re trying to do.
 
When the goal is to use “raw OpenGL (ES 2)” on an embedded system then maybe this one here is for you
 
  http://blog.qt.digia.com/blog/2014/07/02/qt-weekly-16-qquickwidget/
 
In fact, the main advantage of using a QQuickWidget (for a QWidget-based application) instead of the QGLWidget (which is to be replaced by a new QOpenGLWidget and all related QOpenGL* classes) is that it does not require a “native window”:
 
“As the name suggests, this, as opposed to QQuickWindow and its convenience wrapper QQuickView, is a regular QWidget-derived class. Unlike QGLWidget, it carries no surprises: this is like a normal widget, no native windows will get created behind your back. This comes at a minor cost of course: the OpenGL rendering of the Qt Quick scene is done into a framebuffer object. The compositing is handled transparently by the widget stack.”
 
I have no experience (yet) with that widget, but most obviously the “traditional initializeGL, paintGL and resizeGL” methods are missing. Also, the main purpose seems to be (given the class’ name) to display QML content. But to my minimal knowledge about QML/QtQuick scene graphs you can combine them with “raw OpenGL code”, as is displayed in the example here:
 
  http://qt-project.org/doc/qt-5/qtquick-scenegraph-openglunderqml-example.html
 
However while having a quick look at that example I just realised that it seems to rely on http://qt-project.org/doc/qt-5/qquickwindow.html#beforeRendering which is called from the “scene graph render thread”. QQuickWidget on the other hand doesn’t seem to have such a functionality to “inject RAW OpenGL” into the scene graph. In fact, the docs about QQuickWidget even state (at the very end):
 
“Note: Using QQuickWidget disables the threaded render loop on all platforms. This means that some of the benefits of threaded rendering, for example Animator classes and vsync driven animations, will not be available.”
 
So that might mean “no RAW OpenGL rendering” either. But I don’t know for sure.

Anyway, the blog entry might give you some ideas about what can all go wrong when trying to embed a QWidget based application.
 
 
However another approach could be simply to go with the QWindow approach (if this is feasible on an embedded system – but my understanding is that a QWindow would not request a “native window handle” from the underlying window manager (which might not exist at all on embedded systems), but rather “the entire framebuffer.
 
Anyway, this approach is “the most lightweight access” from Qt to OpenGL. Have a look at this example:
 
  http://qt-project.org/doc/qt-5/qtgui-openglwindow-example.html
 
 
All of the above off course implies that you’re drawing with OpenGL “the Qt way”: that is, you’re not supposed to fetch a “platform specific window/framebuffer handle” and then go on with that in a platform-specific manner. Rather, the above classes are meant to provide a “ready to OpenGL draw” environment, including a valid OpenGL context.
 
By the way, you can also embed a QWindow (which is really a “top-level window” of its on) into a QWidget-based application with QWidget::createWindowContainer. That works okay for desktop applications (at least not worse than with the known issues with a QGLWidget – for instance “overlay”/widget stacking issues), but as the blog (first link) sais: there are issues especially on embedded systems where it might simply fail to try to create such a window container, as this will transform all your widgets into “native windows” – which might simply not be supported by the underlying “Qt platform plugin”.
 
 
As for the error message “Cannot make QOpenGLContext current in a different thread”: this is probably Qt trying to prevent you from shooting into your foot ;) As you know OpenGL does support multiple threads: but each thread is required to have its own distinct OpenGL context (which can share resources with others, though). I understand that you have your own rendering thread, so I assume you probably instantiate your QGLWidget (and the corresponding QOpenGLContext) in the “main” (aka “GUI”) thread, but then try to activate the QOpenGLContext in your own, separate “rendering thread” – that doesn’t work.
 
Then thing is: in order to make a QOpenGLContext “current” (or “active”) (note: the old QGLWidget still uses the old QGLContext in its API, but under the hood that is just a “wrapper” around the new QOpenGLContext that you’re supposed to use now) you need a valid OpenGL “surface” (by creating e.g. at least a QWindow with an OpenGL surface):
 
  http://qt-project.org/doc/qt-5/qopenglcontext.html#makeCurrent
 
You could try to instantiate such a widget/QWindow and the corresponding QOpenGLContext in your own rendering thread – or at least try to instantiate the QOpenGLContext in your own rendering thread. But not sure whether that would work.
 
Cheers, Oliver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140808/48c2dd44/attachment.html>