[osg-users] Qt5 integration

[James Turner]

> On 18 Aug 2015, at 09:44, John Vidar Larring <john.larring at chyronhego.com> wrote:
> 
> I've attempted to update the osgQt code to use the new QOpenGLWidget rather than the deprecated QGLWindow currently subclassed, but I've hit a snag with the the order of when when QOpenGLContext is created and when CompositeViewer expects it to be available (Probably a silly mistake that I'm overlooking). Have you had to restructure the osgQt::GraphicsWindow or osgQt::GLWindow class and the osgViewerQt example in any way to get your implementation to work? 

I’ve had to restructure osgViewerQt a little, because I didn’t try to get the CompositeViewer working yet.

> 
> Also, I would like to know why you chose to use QOpenGLWindow rather QOpenGLWidget considering the Qt documenation below.
> 
> From http://doc.qt.io/qt-5/qopenglwidget.html <http://doc.qt.io/qt-5/qopenglwidget.html>:
> 
> Adding a QOpenGLWidget <http://doc.qt.io/qt-5/qopenglwidget.html> into a window turns on OpenGL-based compositing for the entire window. In some special cases this may not be ideal, and the old QGLWidget-style behavior with a separate, native child window is desired. Desktop applications that understand the limitations of this approach (for example when it comes to overlaps, transparency, scroll views and MDI areas), can use QOpenGLWindow <http://doc.qt.io/qt-5/qopenglwindow.html> with QWidget::createWindowContainer <http://doc.qt.io/qt-5/qwidget.html#createWindowContainer>(). This is a modern alternative to QGLWidget and is faster than QOpenGLWidget <http://doc.qt.io/qt-5/qopenglwidget.html> due to the lack of the additional composition step. It is strongly recommended to limit the usage of this approach to cases where there is no other choice. Note that this option is not suitable for most embedded and mobile platforms, and it is known to have issues on certain desktop platforms (e.g. OS X) too. The stable, cross-platform solution is always QOpenGLWidget <http://doc.qt.io/qt-5/qopenglwidget.html>.

My personal take is that the QOpenGLWidget approach is inferior to the QOpenGLWindow+createWindowContainer approach, because of the slightly rapid way it was introduced, and the tradeoffs it makes in composting the different elements. However, this is subjective, and I will cheerfully support both, because as the documentation you pasted notes, there are cases where each approach is better or worse.

Note that from my understanding, the QOpenGLWidget approach will effectively force OSG into single threaded mode, becuase tge API gives no control over when makeCurrent is called, or which thread paintGL is called on. (But I need to check this with some colleagues and lazlo who created the code). In contrast my QWindow-based approach supports all the OSG threading modes directly.

I expect to end up with three different window options:

	- osgQt::GraphicsWindowQt5 - gives you a QWindow, can be embedded with createWindowContainer or used standalone

	(QtGui dependency only)

	- osgQt::GraphicsWidget - gives you a QOpenGLWidget

	(QtWidget dependency)

	- osgQt::GraphicsWindowQtQuick - gives a window similar to QQuickWindow/QQuickView which can have a QML file setSource()-ed on it

	(QtGui + QtQuick2 dependency)

I have the first case done, will work on the second and third cases now, before worrying about QWidgetImage and other less common forms of integration.

Kind regards,
James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150824/76912efb/attachment-0003.htm>