<p dir="ltr"><br>
On Jun 30, 2016 1:19 AM, Elvis Stansvik <elvis.stansvik@orexplore.com> wrote:<br>
><br>
> 2016-06-29 22:52 GMT+02:00 <clinton@elemtech.com>:<br>
>><br>
>><br>
>><br>
>> ----- On Jun 29, 2016, at 10:45 AM, Elvis Stansvik <elvis.stansvik@orexplore.com> wrote:<br>
>>><br>
>>><br>
>>> Den 29 juni 2016 6:07 em skrev "Shawn Waldon" <shawn.waldon@kitware.com>:<br>
>>> >><br>
>>> >><br>
>>> >> 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.<br>
>>> >><br>
>>> >> 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.<br>
>>> >><br>
>>> >> 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.<br>
>>> >><br>
>>> >> 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.<br>
>>> >><br>
>>> >> 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?<br>
>>> ><br>
>>> ><br>
>>> > 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.<br>
>>> ><br>
>>> > 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.<br>
>>><br>
>>> Do you know which features and if this is being worked out?<br>
>><br>
>><br>
>> I'm aware of some issues, and have looked briefly at Linux specific issues.<br>
>> For instance, QVTKWidget::x11_setup_window is disabled for Qt5 and there has not been a replacement for that yet.<br>
><br>
><br>
> Alright, good to know, thanks.<br>
> <br>
>><br>
>><br>
>> One possible workaround is to do something like the following in your main() before the QApplication is constructed.<br>
>><br>
>> QSurfaceFormat fmt;<br>
>><br>
>> fmt.setDepthBufferSize(8);<br>
>><br>
>> fmt.setSamples(1);<br>
>><br>
>> fmt.setAlphaBufferSize(8);<br>
>><br>
>> fmt.setStereo(1);<br>
>><br>
>> fmt.setStencilBufferSize(8);<br>
>> QSurfaceFormat::setDefaultFormat(fmt);<br>
>><br>
>><br>
><br>
> 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?</p>
<p dir="ltr">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.</p>
<p dir="ltr">That setup is in addition to setting a format for an opengl context.</p>
<p dir="ltr">><br>
>><br>
>> It does fix some issues I'm able to replicate with the OpenGL backend.<br>
>> For OpenGL2 backend, and possibly applicable to any platform, perhaps you could try adding a<br>
>><br>
>> fmt.setMajorVersion(3);<br>
>><br>
>> fmt.setMajorVersion(2);<br>
><br>
><br>
> 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.<br>
> <br>
>><br>
>> However, that may not be necessary because in the case of QVTKWidget, VTK is creating OpenGL contexts, not Qt.<br>
><br>
><br>
> Right, that's what I also found out when looking at the code.<br>
> <br>
>><br>
>><br>
>> 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.<br>
><br>
><br>
> 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.<br>
><br>
> 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?<br>
> <br>
>><br>
>> Anyway, perhaps these workarounds will help.<br>
><br>
><br>
> 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.<br>
></p>
<p dir="ltr">In the implementation for QOpenGLWidget, they may extract a QSurfaceFormat from the QGLFormat you give. So, it's possible It may not change anything.<br></p>
<p dir="ltr">> 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.<br>
></p>
<p dir="ltr">I don't have enough experience with some of those combinations to give a suggestion.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Clint</p>