I started digging around, and it seems the problem can also be “fixed” by using a OpenGL compatibility profile instead of core profile (which is what
QVTKOpenGLWidget::defaultFormat()returns).
The problem is not appearing on our Linux or macOS test machines, only on the Windows 10 machine (Intel graphics, though not sure that matters).
I believe it does matter. IIRC, compatibility profile is legacy OpenGL (version <= 2) where you only have fixed functions (no shaders; software rendering only), while core profile is modern OpenGL (includes shaders; render on gpu).
Windows ships with legacy OpenGL (in case you don’t have hardware to support modern OpenGL). Even though switching to compatibility profile will make it work, you’re likely not getting minimal (if any) hardware acceleration.
When we add some actors to the renderer during runtime and then call
Render(), the rendering seems ineffective (nothing shows up) until the user resizes the widget a little (causing a second render).
Has anyone seen this problem before?
Yes, I see this as well. You can refer to my issue QPainter::begin: Paint device returned engine == 0, type: 1. I added gif’s showing this exact problem.
This is independent of QVTKOpenGLWidget. In my example, I inherit from QWidget. I’m able to recreate the problem without using QVTKOpenGLWidget at all.
Since Qt4, all QWidget’s are double-buffered, and WA_PaintOnScreen was added for backwards-compatibility to allow setting a widget to use single buffering.
I believe the issue stems from how VTK interprets how Qt version >=4 renders. I think it is still interpreting that Qt is single-buffered by default.