[vtkusers] Find reason for exclusion of vtkGUISupportQtOpenGL in build output?

[Elvis Stansvik]

2016-06-30 14:31 GMT+02:00 <clinton at elemtech.com>:

>
> On Jun 30, 2016 1:19 AM, Elvis Stansvik <elvis.stansvik at orexplore.com>
> wrote:
> >
> > 2016-06-29 22:52 GMT+02:00 <clinton at elemtech.com>:
> >>
> >>
> >>
> >> ----- On Jun 29, 2016, at 10:45 AM, Elvis Stansvik <
> elvis.stansvik at orexplore.com> wrote:
> >>>
> >>>
> >>> Den 29 juni 2016 6:07 em skrev "Shawn Waldon" <
> shawn.waldon at kitware.com>:
> >>> >>
> >>> >>
> >>> >> I see, I may have misunderstood the role of QVTKWidget2 is vs
> QVTKWidget. I thought QVTKWidget2 was essentially a newer replacement for
> QVTKWidget, and to be preferred in new code.
> >>> >>
> >>> >> I've also misunderstood a little how the two widgets work. I knew
> QVTKWidget2 makes use of the deprecated QGLWidget (and was in fact trying
> to make a similar Python class just recently, which uses QOpenGLWidget, but
> ran into some problems). But I also wrongly thought that QVTKWidget used
> QGLWidget, looking at the code I see now that it doesn't.
> >>> >>
> >>> >> So in short: I have no great need for QVTKWidget2,
> functionality-wise. So if using it precludes using the OpenGL2 backend,
> I'll use QVTKWidget instead.
> >>> >>
> >>> >> One thing I did like was that the code in QVTKWidget2 looked a
> little simpler/cleaner than the one QVTKWidget. It's always nice to be able
> to quickly check how something work.
> >>> >>
> >>> >> An officially supported widget, based on QOpenGLWidget and
> supporting the OpenGL2 backend, would be the absolutely best of course. In
> fact, there's an answer on StackOverflow where a user posted his
> QVTKWidget2 hacked to work with QOpenGLWidget [1], perhaps it could be used
> as a starting point?
> >>> >
> >>> >
> >>> > So just to throw this out there, here is the situation as I
> understand it.  Ben (cc'd) can correct what I get wrong since he was one of
> the last to touch QVTKWidget2.
> >>> >
> >>> > QVTKWidget works fine with OpenGL2 if you are building against Qt4.
> But when you build for Qt5 there are issues with creating the OpenGL
> context and letting Qt know the context is there and so some features of
> the OpenGL2 backend don't work right.
> >>>
> >>> Do you know which features and if this is being worked out?
> >>
> >>
> >> I'm aware of some issues, and have looked briefly at Linux specific
> issues.
> >> For instance, QVTKWidget::x11_setup_window is disabled for Qt5 and
> there has not been a replacement for that yet.
> >
> >
> > Alright, good to know, thanks.
> >
> >>
> >>
> >> One possible workaround is to do something like the following in your
> main() before the QApplication is constructed.
> >>
> >>     QSurfaceFormat fmt;
> >>
> >>     fmt.setDepthBufferSize(8);
> >>
> >>     fmt.setSamples(1);
> >>
> >>     fmt.setAlphaBufferSize(8);
> >>
> >>     fmt.setStereo(1);
> >>
> >>     fmt.setStencilBufferSize(8);
> >>     QSurfaceFormat::setDefaultFormat(fmt);
> >>
> >>
> >
> > Hm, but isn't QSurfaceFormat only about the context set up by the new
> (or well, somewhat new) QOpenGLWidget? If you mean you are using a context
> from QGLWidget (through QVTKWidget2), then shouldn't QGLFormat be used
> instead?
>
> QSurfaceFormat is about creating a QWindow (this corresponds to an x11
> window created by xcb_create_window) that supports the requested features.
> Setting the default surface format fixes what looked like a broken depth
> buffer under some combinations of xserver settings and opengl drivers.
> Getting a good QWindow is needed for QVTKWidget.
>
> That setup is in addition to setting a format for an opengl context.
>
Aha, thanks for clarifying. I had missed that QSurfaceFormat has this
broader purpose.

> >
> >>
> >> It does fix some issues I'm able to replicate with the OpenGL backend.
> >> For OpenGL2 backend, and possibly applicable to any platform, perhaps
> you could try adding a
> >>
> >>     fmt.setMajorVersion(3);
> >>
> >>     fmt.setMajorVersion(2);
> >
> >
> > Yes, this is what I did (and also
> fmt.setProfile(QSurfaceFormat.CompatibilityProfile) when experimenting with
> trying to get a QOpenGLWidget-backed widget working from Python (á la
> http://stackoverflow.com/questions/26944831/using-qvtkwidget-and-qopenglwidget-in-the-same-ui/26946040#26946040),
> in order for VTK to accept the context.
> >
> >>
> >> However, that may not be necessary because in the case of QVTKWidget,
> VTK is creating OpenGL contexts, not Qt.
> >
> >
> > Right, that's what I also found out when looking at the code.
> >
> >>
> >>
> >> I do not yet see a way for that information to be passed from
> vtkRenderWindow to QVTKWidget and down to Qt after the QApplication has
> been constructed.
> >
> >
> > With "that information", do you mean information about what OpenGL
> version the render needs? No I guess not, I guess you just have to target a
> certain VTK version and use fixed numbers in the calls to
> .setMajor/MinorVersion.
> >
> > But, like you say, with QVTKWidget, VTK is creating the OpenGL context,
> so there's nothing to .setMajorMinor/Version on, or am I missing something?
> >
> >>
> >> Anyway, perhaps these workarounds will help.
> >
> >
> > I'm not sure, if QSurfaceFormat is only for QOpenGLWidget, I would have
> to have a working QOpenGLWidget-based VTK widget first. But it was
> interesting that you set the depth/alpha/stencil buffers as well, since I
> only used it to set the number of samples when I experimented with
> QOpenGLWidget. Perhaps I should give it a try again.
> >
>
> In the implementation for QOpenGLWidget, they may extract a QSurfaceFormat
> from the QGLFormat you give.  So, it's possible It may not change anything.
>
Yea, I guess it might.

> > In the end, I would still be very interested to hear if anyone knows
> what would be the best backend + VTK widget to use given the hardware I
> need to support.
> >
>
> I don't have enough experience with some of those combinations to give a
> suggestion.
>
Alright, I guess the best thing is to just try.

> My hope with the QSurfaceFormat suggestion is to give you a better working
> Qt5 + QVTKWidget + OpenGL/OpenGL2 combination due to a bit of un-ported
> code.
>
Yep, thanks a lot, I'll have to do some tests.

Elvis


> Clint
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160630/8b61d268/attachment.html>