[osg-users] Qt5 integration

[John Vidar Larring]

Hi James,

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?

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:

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>.

Would love to see / contribute / comment on your osg qt5 integration.

Best  regards,
John

On Thu, Aug 13, 2015 at 10:10 PM, James Turner <zakalawe at mac.com> wrote:

> Hi,
>
> I’ve been re-working the osgQt code to fit the Qt5 windowing model closer
> - I have a basic proof of concept working, which I will clean up and
> publish shortly. This provides an osgViewer backed by a QWindow; so the
> widget and opengl module dependency is gone, the only Qt5 modules needed
> are Gui and Core.
>
> A QWindow can be embedded in a traditional widget based application using
> QWidget::createWindowContainer; I will create an example of this approach
> as part of my submission. (And the performance of this approach is the same
> as the old QGLWidget inside GraphicsWindowQt).
>
> What I’d like to know, is what other uses cases are relevant for people:
>
> - I could re-create QWidgetImage, but using QWidget::render and avoiding
> any reliance on QGraphicsScene or QGraphicsProxy. If people have uses cases
> for QWidgetImage, that would be good to know. Especially, are you embedding
> ‘a few buttons’ or entire application layouts? Correctly handling keyboard
> focus is obviously something that’s been difficult in the current code and
> I expect to be similarly awkward.
>
> - QtQuick2 integration; I’ll create a custom QQ2 item which renders OSG
> via a framebuffer. This will allow an OSG scene to be integrated with QQ2
> UI, with reasonable performance. I would welcome any input from people who
> need this, and your particular requirements, especially the API for binding
> the osg Scene to the QML item. But, see the next point:
>
> - I /hope/ to create a GraphicsWindowQtQuick which allows the common case
> of an OSG scene, with a QQ2 scene overlaid. This has some complexities to
> support the different OSG threading models and context lifetime, but it
> feels like such a common and desirable use case it’s worth spending time on.
>
> - does anyone have a use for an equivalent of QWidgetImage for QtQuick2?
> I.e a chunk of QQ2 content displayed as a texture.
>
> My intention would be to have any new classes live alongside the existing
> Qt4 support, since I don’t want to touch that code at all, for fear of
> regressing some aspect of the Qt4 support which someone may be relying upon
> in existing code.
>
> If you have thoughts in this area, interesting requirements which might
> guide my approach, or test-case you can share, please let me know. I will
> definitely  be doing the basic pieces outlined above, but whether I work on
> the QWidgetImage piece in particular depends very much on what response I
> get.
>
> Kind regards,
> James Turner
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
> --
> This email was Anti Virus checked by Astaro Security Gateway.
> http://www.sophos.com
>
>
> --
> This email was Anti Virus checked by Astaro Security Gateway.
> http://www.sophos.com
>



-- 

<http://chyronhego.com/press-release/chyronhego-nab-show-2015-product-preview>
<http://chyronhego.com/press-release/chyronhego-nab-show-2015-product-preview>

*John Vidar Larring* *| Senior Developer*

*ChyronHego Norge AS* *- *Sandakerveien 114a, 0484 Oslo, Norway
Office. +47 2279 7030 - Mobile.+47 4889 9795 - www.chyronhego.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150818/5431581e/attachment-0003.htm>