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

With compatibility profile […] SUCCESS

After chatting with @ken-martin, this is most like due to an issue in Qt, compatibility mode should be used on Windows.

@ben.boeckel would QTBUG-60742 be related to this ?

We did not have this issue with VTK 8.1.2 (so with QVTKOpenGLNativeWidget, or QVTKOpenGLWidget as it was called there), using the same Qt version. Did something change in VTK which triggers this Qt bug?

I’m not sure QTBUG-60742 is this particular issue (if I understand that bug report right). When I was debug printing stuff a few days ago, I seem to remember debug printing the QSurfaceFormat that the underlying QOpenGLContext actually had gotten, and it looked alright. But I can double check.

Not doubting it’s a Qt issue, just not sure it’s that particular one…

If it is a Qt issue, it would be good if it’s identified and reported, so we can stick a link to that report in a comment where we work around it by setting a compat profile.

I don’t think that specific Qt issue is related here either. That one is mostly about Mesa which gives the minimum profile without any attributes to say otherwise. IIRC, Windows drivers tend to give the max profile by default (which I believe is against the spec) and Qt’s logic fails with Mesa.

I think that’s what I saw too in my debug printing. If not doing anything, the profile that was in effect looked very featureful.

It sounds like you have a good handle on what happens in Qt WRT to this.

As for this issue, we’ll be doing

    auto format = QVTKOpenGLWidget::defaultFormat();
#if defined(Q_OS_WIN)
    // On Windows we use a compatibility profile to work around
    // https://gitlab.kitware.com/vtk/vtk/issues/17572
    //
    // See also our Discourse post at
    // https://discourse.vtk.org/t/problem-in-vtk-8-2-with-defaultformat-and-qvtkopenglwidget-on-windows-10-intel
    format.setProfile(QSurfaceFormat::CompatibilityProfile);
#endif
    QSurfaceFormat::setDefaultFormat(format);

in the meantime, until it is figured out why things don’t work out-of-the-box with core profile.

I can help out with debugging, but I think it’s rather easy to reproduce (Win 10 / Intel HD graphics, not sure if the exact GPU model or driver version is important). I’m afraid I don’t really have much skill in OpenGL. I can try to figure out why paintGL of the underlying QVTKOpenGLWindow seems to not be called when Render is called.

Thanks for the update. That said, do you know if the particular problem discussed here has been reported to Qt.

It sounds like you have a good handle on what happens in Qt WRT to this.

Only insofar as trying to get Mesa working on Windows guided me.

That said, do you know if the particular problem discussed here has been reported to Qt.

I haven’t reported it. If someone can give me a description, I already have a Qt account to file it with. I also haven’t searched for it either.

Has it been ruled out that this is a bug in VTK yet though? It works on Linux and Mac, and it works with the old VTK widget (QVTKOpenGLNativeWidget aka QVTKOpenGLWidget in older VTKs). Could it not be some missing event handling or something in the new widget?

The smallest reproducer I have is the VTK program in my post above. I’m not sure how I would go about reproducing it without VTK (just plain QOpenGLWidget).

Probably VTK probably does something “special”. It may be a valid operation but it is something uncommon, that most other applications don’t do.

I’ve found that in Slicer if I start up the application without having any QVTK widget and then later add a QVTK widget to the layout then the problem does not occur.

I think you’re right @lassoan , just remains to find what that “special” thing is, and if it’s a valid assumption by VTK or not.

That it works by later adding a QVTK widget I guess could be simply that circumstances causes two renders (so the bug won’t manifest itself). I think I noticed something similar in our app while I was playing around: We have a QVTKOpenGLNativeWidget in another place, and if that widget is initially visible (it’s normally not, but I hacked it to be so), then the QVTKOpenGLWidget did not seem to exhibit the bug.

We have done some more research and testing in 3D Slicer and the conclusion is the following:

Why the problem occurs? If an application does not work correctly with a core profile then it indicates that still some old API or methods are used somewhere. Of course it may also mean that there are some other OpenGL handling mistakes that happen to not cause any problems when a compatibility profile is used. Qt is supposed to fully support core profiles since Qt-5.10, but it is a large project, so maybe there are still some issues. Overall, it is somewhat more likely that VTK has some OpenGL usage related bug, most probably related to initialization (as the application works well even with core profile, depending on what the main application window contains on application startup). We will not spend more time trying to pinpoint the issue, hopefully it will come up and fixed in another scenario (either in VTK or Qt).

What is the solution? We have decided to use compatibility profile for Windows, and core profile on Mac & Linux. Compatibility profiles are not fully supported on Mac, so core profile must be used there. We added an application setting option (not exposed on the application user interface) that allows forcing compatibility/core profile so that we can experiment with it and users can override it as needed.

Any regressions or risks of regressions? Using a compatibility profile on Windows does not seem to have any disadvantages. Performance may be even better than with a core profile.

Thanks @lassoan , we have done the same thing (sans the runtime toggle). Would of course really like to track this down, if it’s in VTK or Qt (like you, I suspect the former).

@lassoan Just thought I should ask: Have you guys ran into any trouble on macOS after porting to the new widget?

After some more testing here, I realised that we have a serious issue on macOS as well - one of our VTK windows will not update/re-render until you resize the window a little, or if you Command+Tab to another application and back again. That particular widget is in a tab in a QTabWidget (though I’m not sure that has any relevance, just that we have another VTK widget that also uses the same new QVTKOpenGLWidget, and it seems to work alright, and it’s not in a QTabWidget).

Just thought I should ask, since the problem seems slightly similar to this one.

(We are currently running with the same workaround as you guys, compete profile on Windows, core profile (the default) on Linux and macOS)

@utkarshayachit may confirm, but we are always using QVTKOpenGLNativeWidget on MacOS in ParaView as they are way too many bugs in Qt in this case.

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?