[vtkusers] Find reason for exclusion of vtkGUISupportQtOpenGL in build output?
Elvis Stansvik
elvis.stansvik at orexplore.com
Thu Jun 30 14:15:19 EDT 2016
2016-06-30 20:11 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> 2016-06-30 15:05 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>
>> 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.
>>> >>
>>>
>>
> Here's my experience with these flags after testing a little with
> QVTKWidget + Qt5 + OpenGL2 backend:
>
>> >> QSurfaceFormat fmt;
>>> >>
>>> >> fmt.setDepthBufferSize(8);
>>>
>> I haven't found a need for this one yet.
>
>> >>
>>> >> fmt.setSamples(1);
>>>
>> This one I changed to 8, to get anti-aliased output. But it's nice to
> know that I now have a place to control it.
>
>> >>
>>> >> fmt.setAlphaBufferSize(8);
>>>
>> Haven't found a need for this one yet either.
>
>> >>
>>> >> fmt.setStereo(1);
>>>
>> I don't have a need for stereo rendering I think, and on my old
> Sandybridge (HD 3000 graphics) laptop at work I got a segfault when winId
> was called by QVTKWidget to configure the render window:
>
Sorry I should have been clearer: I got the below segfault when I ran with
setStereo(1).
Elvis
> (gdb) bt
> #0 0x00007fffb9436119 in ?? () from
> /usr/lib/qt/plugins/xcbglintegrations/libqxcb-glx-integration.so
> #1 0x00007fffbba09726 in QXcbWindow::create() () from
> /usr/lib/libQt5XcbQpa.so.5
> #2 0x00007fffbb9f5da0 in QXcbIntegration::createPlatformWindow(QWindow*)
> const () from /usr/lib/libQt5XcbQpa.so.5
> #3 0x00007fffe53c6d39 in QWindowPrivate::create(bool) () from
> /usr/lib/libQt5Gui.so.5
> #4 0x00007fffe5b89ba3 in QWidgetPrivate::create_sys(unsigned long long,
> bool, bool) () from /usr/lib/libQt5Widgets.so.5
> #5 0x00007fffe5b893ad in QWidget::create(unsigned long long, bool, bool)
> () from /usr/lib/libQt5Widgets.so.5
> #6 0x00007fffe5b897ac in QWidgetPrivate::createWinId() () from
> /usr/lib/libQt5Widgets.so.5
> #7 0x00007fffe5b89819 in QWidget::winId() const () from
> /usr/lib/libQt5Widgets.so.5
> #8 0x00007fffe5b899a8 in ?? () from /usr/lib/libQt5Widgets.so.5
> #9 0x00007fffe5b89bf8 in QWidgetPrivate::create_sys(unsigned long long,
> bool, bool) () from /usr/lib/libQt5Widgets.so.5
> #10 0x00007fffe5b893ad in QWidget::create(unsigned long long, bool, bool)
> () from /usr/lib/libQt5Widgets.so.5
> #11 0x00007fffe5b897ac in QWidgetPrivate::createWinId() () from
> /usr/lib/libQt5Widgets.so.5
> #12 0x00007fffe5b89819 in QWidget::winId() const () from
> /usr/lib/libQt5Widgets.so.5
> #13 0x00007fffe5b899a8 in ?? () from /usr/lib/libQt5Widgets.so.5
> #14 0x00007fffe5b89bf8 in QWidgetPrivate::create_sys(unsigned long long,
> bool, bool) () from /usr/lib/libQt5Widgets.so.5
> #15 0x00007fffe5b893ad in QWidget::create(unsigned long long, bool, bool)
> () from /usr/lib/libQt5Widgets.so.5
> #16 0x00007fffe5b896c8 in QWidgetPrivate::createWinId() () from
> /usr/lib/libQt5Widgets.so.5
> #17 0x00007fffe5b896c8 in QWidgetPrivate::createWinId() () from
> /usr/lib/libQt5Widgets.so.5
> #18 0x00007fffe5b89819 in QWidget::winId() const () from
> /usr/lib/libQt5Widgets.so.5
> #19 0x00007fffe64b958b in QVTKWidget::SetRenderWindow(vtkRenderWindow*) ()
> from /usr/lib/libvtkGUISupportQt.so.1
> #20 0x00007fffe64b87e0 in QVTKWidget::GetRenderWindow() () from
> /usr/lib/libvtkGUISupportQt.so.1
> #21 0x00000000004069f9 in SampleWidget::SampleWidget(QWidget*,
> QFlags<Qt::WindowType>) ()
> #22 0x0000000000406040 in Ui_MainWindow::setupUi(QMainWindow*) ()
> #23 0x00000000004058f9 in MainWindow::MainWindow(QWidget*) ()
> #24 0x000000000040569f in main ()
> (gdb)
>
> On my newer Haswell (HD 4400) laptop at work it worked without problems. I
> don't know if this is a Qt bug, or just a limitation of the weak graphics
> in my home laptop, or something else.
>
>> >>
>>> >> fmt.setStencilBufferSize(8);
>>>
>> This one indeed made a difference, because without it I got weird
> rendering with the poly cylinder I was testing with: It was as if you could
> see "into" the cylinder.
>
> I also noticed I could do
>
> auto window = windowHandle();
>
> if (window) {
> QSurfaceFormat surfaceFormat = window->format();
> surfaceFormat.setDepthBufferSize(8);
> surfaceFormat.setSamples(8);
> surfaceFormat.setAlphaBufferSize(8);
> surfaceFormat.setStencilBufferSize(8);
> surfaceFormat.setStereo(1);
> window->setFormat(surfaceFormat);
> } else {
> qWarning("Can't set surface format: No associated QWindow");
> }
>
> in the constructor of my QVTKWidget base class, instead of setting the
> default surface format before the QApplication is constructed.
>
> Elvis
>
> >> 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/6575d6b4/attachment.html>
More information about the vtkusers
mailing list