Problem in VTK 8.2 with defaultFormat() and QVTKOpenGLWidget on Windows 10/Intel

Alright, thanks for that info @mwestphal. I may try upgrading our Qt to 5.12.3 (using Qt 5.12.0 on macOS at the moment), though I doubt that changes anything. If it doesn’t, I guess we’ll revert to using QVTKOpenGLNativeWidget instead.

We, too, use QVTKOpenGLNativeWidget in most cases. You must use this native variant if the widget is embedded in certain Qt widgets, such as those that can do scrolling, but probably the same is true for tab widget. We only use the non-native for small popup windows.

Right, I’m aware of the restrictions on the QVTKOpenGLWidget, but did not think QTabWidget was one of those circumstances. AFAIK it has no nested QScrollArea or similar inside it.

We have a couple of VTK widgets where we have to use the native widget (e.g. color/opacity settings, similar to Paraview’s situation).

…but, I’m actually pleasantly shocked, because upgrading to Qt 5.12.3 seems to have solved that particular problem I described above.

Still having some problem with another one of our VTK widgets on macOS though, the problem there being that the very first render seems to be a hit and miss (sometimes it works, sometimes it doesn’t, and a resize is necessary to get it back into shape).

QTabWidget does not have these restrictions afaik. They are macOS specific issues though.

Glad an update fixed parts of your issues.

The remaining issue we have on macOS (occurring in just one of our VTK widgets, this time not in a QTabWidget, but just in a QSplitter in our central application area) seems very similar to the issue we had on Windows actually (start of this thread). The initial render is ineffective (sometimes, seems timing dependent/racy), and a resize is required to get it back into shape (after that, it seems to work alright).

I made a separate post with some questions about choosing the native or non-native widget: How to decide between QVTKOpenGL{Native}Widget?