How to decide between QVTKOpenGL{Native}Widget?

(Elvis Stansvik) #1

Hi all,

The advice in the thread “the New QVTKOpenGLWidget” on the development mailing list read:

**1. Why is there a new widget and what does it do ?**

We have been having some issues reported for the old widget, and the old widget could not support quad buffer stereo rendering by design.

Has it is a needed feature in ParaView, a reimplementation was necessary. This new widget fix most of the reported issues with the old widget as well as adding stereo support.

**2. Why keeping the old widget around then ?**

Due to Qt limitations, this new implementation does not support very well being a native widget.

But native widget are sometimes mandatory, for example within QScrollArea and QMDIArea, so the QVTKOpenGLSimpleWidget should be used when in needs of VTK rendering in the contact of Qt native widget.

Also it allows users to switch back to the old widget if necessary.

**3. I'm not sure what native widgets are, what should I do in my application ?**

Here are the different situation :

1. Your Qt application only uses a central QVTKOpenGLWidget for rendering:
-> Nothing to do, just build with last master and make sure all is working well
2. Your Qt application only uses QVTKOpenGLWidget within QScrollArea or QMDIArea, or manually set widgets to be native and you are not interested by stereo rendering.
-> Change all your QVTKOpenGLWidget to QVTKOpenGLSimpleWidget and you are good to go
3. Your application uses a non-native QVTKOpenGLWidget for rendering as well as native QVTKOpenGLWidget for rendering (eg: ParaView, with the central rendering widget and the color map editor rendering widget in scroll areas) :
-> Use QVTKOpenGLWidget for non-native widgets and QVTKOpenGLSimpleWidget for native ones. The later will never support stereo.

**4. I followed your recommendation but I see some strange stuff/bugs/rendering issues**

Even if this new class has been tested extensively and will be used in the next ParaView release, It may still contains some issues. Feel free to discuss them in this mailing list or on our [gitlab](https://gitlab.kitware.com/vtk/vtk).

In our application we use a VTK widget in three places, only two of those required the “old” native widget (because they were nested in a QScrollArea). The other two places we ported to the new widget.

But we ran into problems, first on Windows (see Problem in VTK 8.2 with defaultFormat() and QVTKOpenGLWidget on Windows 10/Intel), which we were able to solve using a workaround, but then also on macOS, which I’ve so far not been able to work around.

The remaining problem we have on macOS is that the initial render sometimes work and sometimes does not. When it doesn’t, the widget is also not responding to input (camera movement). Only by resizing the window (and thus the widget), or by obscuring then revealing the window am I able to get it into a state where it renders properly.

Since I’ve now heard from Paraview devs that it uses the native widget exclusively on macOS, I’m considering going with this as a workaround for now. But this leads me to my question:

**1. Why is there a new widget and what does it do ?**

We have been having some issues reported for the old widget, and the old widget could not support quad buffer stereo rendering by design.

Has it is a needed feature in ParaView, a reimplementation was necessary. This new widget fix most of the reported issues with the old widget as well as adding stereo support.

What are the issues referred to above? And since the old widget is kept (to allow for native contexts), will those issues in it be fixed? (or perhaps they are already?). Unlike ParaView, we do not need support for stereo rendering.

So my question is if there are any downsides with sticking to the native widget in all contexts? We do not seem to suffer from the issues mentioned above (but I’d like to know what they are, to be sure).

Thanks in advance!

Problem in VTK 8.2 with defaultFormat() and QVTKOpenGLWidget on Windows 10/Intel
(Mathieu Westphal (Kitware)) #2

It was related to multiples issues reported on our gitlab that with the old widget:
https://gitlab.kitware.com/vtk/vtk/issues/17154
https://gitlab.kitware.com/vtk/vtk/issues/17138
https://gitlab.kitware.com/vtk/vtk/merge_requests/3973

We however add some issues on the ParaView side with the new implementation, especially on MacOS, which were more problematic than a few artifacts.

@utkarshayachit may know more.

(Elvis Stansvik) #3

Thanks for the pointers @mwestphal!

We have not had problems with line rendering as in the first issue. In two of our widgets, where we do volume rendering, we’ve in fact run with anti aliasing off. This was out of necessity since we were rendering volumes sitting right next to each other, and the MSAA of the two volumes would result in a thin white streak (so similar reason for Paraview not being able to use MSAA for its parallel rendering). Since then we’ve moved to using FXAA instead (post-processing approach), which does not look as nice, but is better than nothing.

For the second issue, we do not have a fullscreen mode in our app, and even so, I’m not sure this would be applicable to us since we use FXAA (?).

And the third link is actually an MR of my own, adding support to the native widget for fractional device pixel ratios :slightly_smiling_face:

All in all, I now think our best course of action is to report the remaining issue we have on macOS, and move back to using the native widget in all contexts. I think that’s easier than doing it selectively only on macOS.

I forgot to say here one detail about the macOS issue we have: It seems to be non-deterministic, sometimes it happens and sometimes not, so I suspect it’s some race somewhere internally (VTK, Qt, driver, …). I can try to make a test case same as I did with the Windows issue.

(Utkarsh Ayachit) #4

I strongly think that is the best way i.e. prefer QVTKOpenGLNativeWidget over QVTKOpenGLWidget – except when quad buffer stereo is needed. The native widget is better approach since the non-native widget relies on QWidget::createWindowContainer which has a slew of complications including poor support on macOS and issues with how events from parent QWidget are forwarded to the internal QWindow.

A separate but perhaps related issue is that I think the widget naming is woefully confusing. I would expect QVTKOpenGLWidget to be a subclass of QOpenGLWidget but it is not. I would recommend we rename the classes as follows:

  1. QVTKOpenGLWidget – currently called QVTKOpenGLNativeWidget, subclass of QOpenGLWidget
  2. QVTKOpenGLWindow – subclass of QOpenGLWindow; this is same as now.
  3. QVTKOpenGLWindowContainerWidget – this is the QWidget subclass that uses QWidget::createWindowContainer to internally manage a QVTKOpenGLWindow for the actual rendering; currently called QVTKOpenGLWidget.
(Mathieu Westphal (Kitware)) #5

Indeed, I agree fully with @utkarshayachit after seeing all the complexity of the work on ParaView side.

(Andras Lasso) #6

I agree with the proposed new names. However, we already caused so much confusion with these class renames and VTK version rollback that it would be better to wait a few years until things settle down. Things may also change in Qt’s MacOS support and MacOS OpenGL support anyway, so we may spare a round of name change if we wait some time.

1 Like
(Utkarsh Ayachit) #7

sounds reasonable.

1 Like
(Elvis Stansvik) #8

Thanks for the further info guys.

We’ve now reverted to using the native widget everywhere since we’re not in need of stereo rendering and things are running smooth on all platforms again.

I agree QVTKOpenGLNativeWidget not being a QOpenGLWidget is confusing and welcome the suggested name changes (now or in a few years).