No, I meant mixing regular widgets with QGLWidget. Like, say, having a QGLWidget as a child of another QWidget, in a layout or in an MDI area, etc. On platforms that restrict themselves to a single native window and window surface this is problematic since a QGLWidget always requires its own window/surface.
QGLWidget, QOpenGLWidget, QQuickWidget all have a dependency on the widgets module. These should only be used when the application needs some other (Q)widgets too. You should not be basing new development on Q(Open)GLWidget if that is not the case. You are absolutely right about QWindow. Using QWindow with a few lines of simple "boilerplate"(?) code is still the way to go, if the design allows it. This avoids the dependency on the widgets module and allows a higher degree of control than QGLWidget could ever offer. However, to make life easier, there are plans about introducing a QOpenGLWindow with an API equivalent to QOpenGLWidget. As the name suggests this would be a convenience wrapper of QWindow without any QWidget dependencies. This could complete the offering in 5.4 as follows: QOpenGLWidget: the successor of QGLWidget. Targeted for mixing native GL content with other widgets. Not recommended for GL-only toplevels due to the implicit compositing step. (*) QQuickWidget: the equivalent for Quick QOpenGLWindow: the lightweight and best performing option for windows that contain nothing but OpenGL content (e.g. games). Can still be "embedded" into a QWidget window using createWindowContainer but a number of restrictions apply (stacking etc.). QQuickWindow/QQuickView: the equivalent for Quick Best regards, Laszlo (*) Unlike QGLWidget, there is no native window under the hood for a (non-toplevel) Q(OpenGL|Quick)Widget. Instead, they render into a framebuffer object. The textures are then composited by the top-level widget. This obviously carries a performance penalty. ________________________________________ From: interest-bounces+laszlo.agocs=digia....@qt-project.org [interest-bounces+laszlo.agocs=digia....@qt-project.org] on behalf of Till Oliver Knoll [till.oliver.kn...@gmail.com] Sent: Tuesday, February 18, 2014 5:27 PM To: Qt Project Subject: Re: [Interest] Platform eglfs and OpenGL Am 18.02.2014 um 15:25 schrieb Agocs Laszlo <laszlo.ag...@digia.com>: > Nothing stops you from "using OpenGL in a Qt application", what you cannot do > is mixing QGLWidget with other widgets. Take hellogl_es2 for example and > strip out the MainWindow with all the widgets. If you only have the QGLWidget > and nothing else, it will work fine on eglfs too. You must have meant "you cannot mix Q*Open*GLWidget" (yet) with QGLWidget? Wasn't there as well the suggestion (in some Qt blog) to use a QWindow with a GL surface (write all the tedious boilerplate code you now are supposed to write yourself *ahem*) and then "wrap" that QWindow into a QWidget (with a "wrapper" class/container: QWidget::createWindowContainer())? And that Q*Open*GLWidget would implement exactly that, so /we/ don't have to write the boilerplate code and basically end up with what we had with the *previous* QGLWidget, except that the new QOpenGL classes grok better together with recent OpenGL 4.x context? So what you suggested is that if I want to start using OpenGL *now* (Qt 5.2) I should be using QWindow with GL surface, write the boilerplate code myself (all that initialiseGL, updateGL, resizeGL stuff) and wrap that into a "QWidget container"? And once Qt >=5.4 appears I would throw away my QWindow based class (see "boilerplate code") and start using Q*Open*GLWidget - correct? Is that the (simplified) story? :) Cheers, Oliver P.S. Yes, we really want *QWidgets* & OpenGL here ;) _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
