[vtkusers] Find reason for exclusion of vtkGUISupportQtOpenGL in build output?
Elvis Stansvik
elvis.stansvik at orexplore.com
Thu Jun 30 14:11:45 EDT 2016
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:
(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/d89603d6/attachment.html>
More information about the vtkusers
mailing list