Open wmvanvliet opened 4 years ago
The upstream version of this code does not appear to use QOpenGLWidget at all:
I have no idea why this is the case. The Mayavi code looks a lot like the upstream code, but there are some differences (such as this one).
I can replicate the problem with this code:
>>> import vtk.qt
>>> vtk.qt.QVTKRWIBase
'QWidget'
>>> vtkmodules.qt.QVTKRWIBase = "QGLWidget"
>>> from mayavi import mlab
>>> mlab.test_plot3d()
QPainter::begin: Paint device returned engine == 0, type: 1
So this does appear to be a legitimate bug, assuming we are supposed to be allowed to set this value. @prabhuramachandran it looks like you added this in https://github.com/enthought/mayavi/commit/36d4bd7cf95b60df53584a21add019af44a0c2b7 / https://github.com/enthought/mayavi/pull/528. Any chance you remember testing this mode or not?
Also possibly related to this:
https://github.com/pyvista/pyvista/pull/498 https://github.com/pyvista/pyvista/issues/473 https://gitlab.kitware.com/vtk/vtk/-/issues/17867 https://discourse.vtk.org/t/vtk-9-pyqt-macos-no-rendering/3358/6
I still don't really understand how these things are supposed to work. :( It will take some reading to figure it out -- no time right now for me to do it but maybe in a few weeks.
@larsoner After debugging in VSCode with the following launch.json
so it will go into packages:
{
"configurations": [
{
"name": "Python: Current File",
"type": "python",
"request": "launch",
"program": "${file}",
"console": "integratedTerminal",
"justMyCode": false
}
],
}
the culprit is rwi.py::QVTKRenderWindowInteractor.paintEngine()
getting called when a Paint
event occurs:
def paintEngine(self):
return None
From the PySide6 QPaintEngine docs (it has nearly 2 years since the OP posted the issue and PySide6 is now supported),
X11
(QPaintEngine.X11 == 0
)Windows
(QPaintEngine.Windows == 1
)My guess is paintEngine
was overriden to return None
(NULL in C++) to avoid the error:
QWidget::paintEngine: Should no longer be called
since when the paintEngine
method is removed from QVTKRenderWindowInteractor
, this happens.
@larsoner @wmvanvliet Linking also to pyvistaqt
discussion QPainter::begin: Paint device returned engine == 0, type: 1.
The culprit appears to be QVTKRenderWindowInteractor.paintEngine()
@larsoner @wmvanvliet The following widget attribute is set in pyvistaqt.rwi::QVTKRenderWindowInteractor.__init__()
:
self.setAttribute(WidgetAttribute.WA_PaintOnScreen)
The PySide6.QtCore.Qt docs state this attribute is only available in X11
and I think paintEngine()
was set to return None
(NULL) on purpose for X11
systems:
Hence this clearly causes a problem on non-X11
systems. An alternative is required for non-X11
systems.
@larsoner @wmvanvliet If either of you are attending SciPy this year, it might be a good opportunity to debug this in a sprint session (July 16-17).
I, unfortunately, will be away on vacation, but since it starts tomorrow and most of the developer community will be there, it would be a good opportunity to debug this.
Linking as well the VTK issue I posted for this: QPainter::begin: Paint device returned engine == 0, type: 1 #18606
I am around at SciPy this year and will be here for the sprints too. I am planning on pushing a quick release soon though before the tutorials.
The upstream version of this code does not appear to use QOpenGLWidget at all:
So this does appear to be a legitimate bug, assuming we are supposed to be allowed to set this value. @prabhuramachandran it looks like you added this in 36d4bd7 / #528. Any chance you remember testing this mode or not?
Unfortunately I do not remember. I suspect I just pulled over code changes from VTK and added them into the Mayavi version which has diverged a bit from VTK. The problem for me of course is that we need to support different VTK versions. I need to revisit the Mayavi version.
@larsoner @wmvanvliet If either of you are attending SciPy this year, it might be a good opportunity to debug this in a sprint session (July 16-17).
I should start attending SciPy... Anyway, great to see this old thread being dug up. If this bug could be fixed, that would finally allow us to comfortably use non-nVidia graphic cards with mayavi.
I intend to put out a release fixing some other issues today but can address this by end of SciPy. My time is extremely limited right now as I rush to prepare for a couple of tutorials, it would really help me if you could summarize how I can reproduce the problem on a conda environment (right now I am on a linux laptop but do have an nvidia card), then I could debug the issue and implement a fix. Some details on what OS and hardware you are looking at would help.
If this is just a matter of merging with upstream VTK changes (https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9048) then that makes my life easy too. Thanks. Please let me know.
@larsoner Posted a minimum example to demonstrate the issue in the second comment in this tread ^^
Merging the upstream VTK changes might solve the issue already.
@prabhuramachandran @wmvanvliet Thank you for your help!
I am available today and tomorrow, should you need any help testing on a Windows 10 machine with an NVIDIA graphics card.
BTW, @prabhuramachandran , I was scratching my head trying to remember where I had seen you before, and then your SciPy 2018 presentation popped up!
3D Visualization with Mayavi | SciPy 2018 Tutorial | Prabhu Ramachandran
Thanks for the great tutorials!
@prabhuramachandran @wmvanvliet Thank you for your help!
I am available today and tomorrow, should you need any help testing on a Windows 10 machine with an NVIDIA graphics card.
Unfortunately, I am swamped today and tomorrow, (I have two tutorials which I am teaching and need to work on the content) we could try tomorrow evening after the back to back tutorials but I will probably be pretty dead by then. I am here all week and also at the sprints. It would be awesome to have this resolved by the end of the conference. Many thanks for offering to help with this, it is much appreciated.
FWIW, pushed a 4.8.0 release just now, will roll the fix for this in the next one.
@prabhuramachandran @wmvanvliet Would I be able to join a sprint via Zoom? I will be in Tahoe with limited Internet connectivity and I'm unsure what my family schedule will be, but I can certainly try to join. Do either of you have a time in mind?
Regardless, I will attempt to provide whatever assistance I can within comments here. This is still fairly new territory for me, so please take any potential "fixes" here with a grain of salt (of course, would be FANTASTIC to follow up with some good unit tests, esp. for regressions).
The pyvistaqt
repo already has pulled in the vtk upstream changes, but the problem persists (at least on my machine). You can find pyvistaqt
's variation of QVTKRenderWindowInteractor
here: pyvistaqt/rwi.py
Considering WA_PaintOnScreen
is claimed only to work for X11
, I modified (the pyvistaqt
) rwi.py
slightly to:
...
59: import os
...
373: if os.name == 'posix':
374: self.setAttribute(WidgetAttribute.WA_PaintOnScreen)
Re-running my MRE:
from pyvistaqt import MainWindow, QtInteractor
from qtpy import QtWidgets
class Window(MainWindow):
def __init__(self):
super().__init__()
self.setWindowTitle('Example')
self.layout_ = QtWidgets.QVBoxLayout()
self.container = QtWidgets.QFrame()
self.container.setLayout(self.layout_)
self.setCentralWidget(self.container)
self.plotter = QtInteractor(parent=self.container)
self.layout_.addWidget(self.plotter)
self.plotter.show()
self.signal_close.connect(self.plotter.close)
app = QtWidgets.QApplication([])
window = Window()
window.show()
app.exec_()
gives the following error:
QWindowsGLContext::makeCurrent: SetPixelFormat() failed (The pixel format is invalid.)
qt.qpa.backingstore: composeAndFlush: makeCurrent() failed
which tells me Qt
isn't picking up on the fact that we are trying to use OpenGL. From the PySide6 QBackingStore docs:
QBackingStore enables the use of QPainter to paint on a QWindow with type RasterSurface. The other way of rendering to a QWindow is through the use of OpenGL with QOpenGLContext .
A QBackingStore contains a buffered representation of the window contents, and thus supports partial updates by using QPainter to only update a sub region of the window contents.
QBackingStore might be used by an application that wants to use QPainter without OpenGL acceleration and without the extra overhead of using the QWidget or QGraphicsView UI stacks. For an example of how to use QBackingStore see the Raster Window Example .
Indeed, PySide
provides an example of how to pull Context Info from the running program. NOTE: This would be good to leverage for future unit tests.
If I change rwi.py
to the following:
I get the following printout:
Qt 6.3.1 (x86_64-little_endian-llp64 shared (dynamic) release build; by MSVC 2019) [limited API]
Python 3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64 bit (AMD64)]
Vendor: NVIDIA Corporation
Renderer: Quadro RTX 8000/PCIe/SSE2
Version: 4.6.0 NVIDIA 516.59
Shading language: 4.60 NVIDIA
Context Format: compatibility version 4.6
Surface Format: compatibility version 4.6
Qt 6.3.1 (x86_64-little_endian-llp64 shared (dynamic) release build; by MSVC 2019) [limited API]
Python 3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64 bit (AMD64)]
Vendor: NVIDIA Corporation
Renderer: Quadro RTX 8000/PCIe/SSE2
Version: 4.5.0 NVIDIA 516.59
Shading language: 4.50 NVIDIA
Context Format: compatibility version 4.6
Surface Format: compatibility version 4.6
QWindowsGLContext::makeCurrent: SetPixelFormat() failed (The pixel format is invalid.)
qt.qpa.backingstore: composeAndFlush: makeCurrent() failed
Adding also the following examples:
I believe with respect to the SetPixelFormat()
error above, the pixel format will have to be properly set per platform. On Windows:
Correspondingly in vtkWin32OpenGLRenderWindow:
virtual void SetupPixelFormatPaletteAndContext (HDC hDC, DWORD dwFlags, int debug, int bpp=16, int zbpp=16)
The pixel format error comes from here:
An important note on differences between QGLWidget
and QOpenGLWidget
:
The key takeaway is this:
While the API is very similar, there is an important difference between the two:
QOpenGLWidget
always renders offscreen, using framebuffer objects.QGLWidget
on the other hand uses a native window and surface. The latter causes issues when using it in complex user interfaces since, depending on the platform, such native child widgets may have various limitations, regarding stacking orders for example.QOpenGLWidget
avoids this by not creating a separate native window.
@wmvanvliet I suspect this is why switching back to QGLWidget
worked for you. The QVTKRenderWindowInteractor
appears designed around this old architecture.
@prabhuramachandran @larsoner After investigating, it looks like QVTKRenderWindowInteractor
will require a rewrite to support the newer QOpenGLWidget
. pyvistaqt has already pulled in the vtk upstream changes, and these do not solve the problem (at least on my Windows 10 machine with an NVIDIA gpu).
Since the QGL
classes are obsolete or near deprecation and the vtk folks have previously explained they don't have time to maintain this, I think it will become more important for mayavi
, pyvista
, and other packages using Qt
to work together towards a solution.
@prabhuramachandran @wmvanvliet @larsoner Digging deeper, I found this interesting article, which may prove valuable when supporting both vtk <= 8
and vkt 9+
:
Widget | Use Case |
---|---|
QVTKWidget | Used to display vtkRenderWindow in Qt's QWidget |
QVTKWidget2 | Used to display vtkRenderWindow in Qt's QGLWidget |
QVTKOpenGLWidget | Used to display vtkRenderWindow in Qt's QWidget |
QVTKOpenGLNativeWidget | Used to display vtkGenericOpenGLRenderWindow in Qt's QOpenGLWidget |
Qt <5.4
, use QVTKWidget2
Qt 5.4+
, VTK <=8.1
, use QVTKOpenGLWidget
for versions Qt 5.4+
, VTK 8.2+
, use QVTKOpenGLNativeWidget
However, in truth, I don't think any of these widgets are available from the vtk 9.1.0 PyPI package.
@prabhuramachandran I'm seeing your name here as a maintainer (you're quite the popular developer!). We may need to have these extras built and added to the vtk PyPI repo so they can be used in upgrading the QVTKRenderWindowInteractor
.
Thanks @adam-grant-hendry for all the additional information!
We could try a zoom meeting during the sprints but I am not sure how effective it will be. Are you around tomorrow evening? We could at least discuss this then.
I think building the extras is not a scalable option as a PyPI wheel would then be built against a very specific Qt version and that would be a nightmare to maintain or even install given the different kinds of environments users have. One option is to decide to not support VTK <= 8.
@prabhuramachandran You're a stud! Can't believe you're still up!
Yes, agreed...I think Zoom won't be very effective. I am around tomorrow evening (only online though).
I think supporting VTK >=9 makes sense. The only reason is the majority of open source package maintainers are worried by the licensing terms of the PyQt libraries, which is why they want to move to PySide. However, additionally there is the issue that the QGL classes are now (or soon becoming) obsolete, which goes beyond PyQt vs PySide.
I haven't heard back from anyone on the pyvista side, but you could certainly do it for mayavi if you get consensus. I guess/believe pyvista might be of the same opinion, but I'm of the opinion that rising tides raise all boats. If you come up with a working solution for mayavi, pyvista and others are soon to follow.
What are your opinions? And what time would you like to meet tomorrow? I'm in California, so our time zones (relative to Texas) won't be too far off.
@prabhuramachandran Actually, instead, I recommend we should look at the source code for
QVTKOpenGLNativeWidget
in
and leverage what source code we can there for QVTKRenderWindowInteractor.py
to make it work.
ASIDE: It also looks like pieces of these classes are deprecated in vtk 9.2, but replaced with different functions.
@prabhuramachandran Another alternative would be to create another PyPI repo for additional dependencies, including these QVTK
classes.
e.g. If you use pylint
and put your configuration settings in a pyproject.toml
, you need the toml
library and the additional way of specifying that as an extra dependency is to add the name of the library in square brackets.
On Windows in PowerShell, this is:
PS> py -m pip install pylint[toml]
Hence we could add/remove pieces as needed. This is similar to how vtkmodules
separated pieces of vtk
into separate modules.
@prabhuramachandran @wmvanvliet @larsoner If I try to switch
if rw: # user-supplied render window
self._RenderWindow = rw
else:
self._RenderWindow = vtkGenericOpenGLRenderWindow()
I get the error:
2022-07-12 11:35:49.389 ( 1.031s) [ ]vtkOpenGLRenderWindow.c:493 ERR| vtkGenericOpenGLRenderWindow (00000233F9899E90): GLEW could not be initialized: Missing GL version
ERROR:root:GLEW could not be initialized: Missing GL version
Even though vtkmodules
ships with vtkglew-9.1dll
. If I run
PS> glewinfo
I get the following glewinfo.txt
, which seems to indicate everything is in order:
I've also run vtkProbeOpenGLVersion-9.1.exe
Do you have any idea what's going wrong here?
@prabhuramachandran @wmvanvliet @larsoner I stumbled upon a bit of blind luck today. When I change rwi.py
to do this:
if rw: # user-supplied render window
self._RenderWindow = rw
else:
self._RenderWindow = vtkRenderWindow()
WId = self.winId()
...
# self._RenderWindow.SetWindowInfo(str(int(WId))) # Comment this out
Here's the full file:
I get no errors on my machine, but 2 windows instead of the intended 1:
When I uncomment
self._RenderWindow.SetWindowInfo(str(int(WId)))
The window is properly embedded, but the errors
QWindowsGLContext::makeCurrent: SetPixelFormat() failed (The pixel format is invalid.)
qt.qpa.backingstore: composeAndFlush: makeCurrent() failed
occur at every paint event
If I print the self._RenderWindow
before and after setting the window info:
print(self._RenderWindow)
self._RenderWindow.SetWindowInfo(str(int(WId)))
print(self._RenderWindow)
The only thing that seems to have changed is the Window Id
.
Is this what is supposed to happen? Do you think Qt
is thinking we are trying to do things on the QMainWindow
(here named Example
), when we are really only trying to do them on the vtkWin32OpenGLRenderWindow
window?
FWIW, pyvista
's MainWindow
class is very straightforward:
"""This module contains a Qt-compatible MainWindow class."""
from __future__ import annotations
from qtpy import QtCore
from qtpy.QtCore import Signal
from qtpy.QtWidgets import QMainWindow, QWidget
class MainWindow(QMainWindow):
"""Convenience MainWindow that manages the application."""
signal_close = Signal()
signal_gesture = Signal(QtCore.QEvent)
def __init__(
self,
parent: QWidget | None = None,
title: str | None = None,
size: tuple[int, int] | None = None,
) -> None:
"""Initialize the main window."""
QMainWindow.__init__(self, parent=parent)
if title is not None:
self.setWindowTitle(title)
if size is not None:
self.resize(*size)
def event(self, event: QtCore.QEvent) -> bool:
"""Manage window events and filter the gesture event."""
if event.type() == QtCore.QEvent.Gesture: # pragma: no cover
self.signal_gesture.emit(event)
return True
return super().event(event)
def closeEvent(self, event: QtCore.QEvent) -> None: # pylint: disable=invalid-name
"""Manage the close event."""
self.signal_close.emit()
event.accept()
@prabhuramachandran @wmvanvliet @larsoner Actually, now that I think of it, this error message does seem consistent with the changes from QGLWidget to QOpenGLWidget.
In particular, for PySide6
and PyQt6
, QVTKRWIBase = 'QOpenGLWidget'
, and one of the notes states
Note: Avoid calling winId() on a QOpenGLWidget. This function triggers the creation of a native window, resulting in reduced performance and possibly rendering glitches.
You can see from the QtWidgets.QWidget docs:
also
Drawing directly to the QOpenGLWidget's framebuffer outside the GUI/main thread is possible by reimplementing paintEvent() to do nothing. The context's thread affinity has to be changed via QObject::moveToThread(). After that, makeCurrent() and doneCurrent() are usable on the worker thread. Be careful to move the context back to the GUI/main thread afterwards.
and
Adding a QOpenGLWidget into a window turns on OpenGL-based compositing for the entire window. In some special cases this may not be ideal, and the old QGLWidget-style behavior with a separate, native child window is desired. Desktop applications that understand the limitations of this approach (for example when it comes to overlaps, transparency, scroll views and MDI areas), can use QOpenGLWindow with QWidget::createWindowContainer(). This is a modern alternative to QGLWidget and is faster than QOpenGLWidget due to the lack of the additional composition step. It is strongly recommended to limit the usage of this approach to cases where there is no other choice. Note that this option is not suitable for most embedded and mobile platforms, and it is known to have issues on certain desktop platforms (e.g. macOS) too. The stable, cross-platform solution is always QOpenGLWidget.
@prabhuramachandran @wmvanvliet @larsoner If I add
window_ = QtGui.QWindow.fromWinId(self.plotter.winId())
self.container = self.createWindowContainer(window_, self)
to my Window.__init__()
method, this resolves the errors:
QWindowsGLContext::makeCurrent: SetPixelFormat() failed (The pixel format is invalid.)
qt.qpa.backingstore: composeAndFlush: makeCurrent() failed
so the final MRE is now
I'm unsure if there is a better way. I'm open to suggestions though.
This and simply adding this check in QVTKRenderWindowInteractor.__init__()
if os.name == 'posix':
self.setAttribute(WidgetAttribute.WA_PaintOnScreen)
solve 100% of the problems for me.
Thanks for the fantastic work on this and for all your efforts. I am very sorry for not responding sooner, I have been a bit busy with the conference and then catching up with work. My hope is that I get this done during the sprints. Thanks again for all your work and finding a solution that works.
Thanks for the fantastic work on this and for all your efforts. I am very sorry for not responding sooner, I have been a bit busy with the conference and then catching up with work. My hope is that I get this done during the sprints. Thanks again for all your work and finding a solution that works.
No apologies necessary! Happy to help.
@prabhuramachandran Please note that my "fix" only works when QVTKRenderWidgetInteractor
subclasses from QWidget
. You must manually change QVTKRWIBase
in vtmodules/qt/init.py to change the base class it derives from
# QVTKRWIBase, base class for QVTKRenderWindowInteractor,
# can be altered by the user to "QGLWidget" or "QOpenGLWidget"
# in case of rendering errors (e.g. depth check problems,
# readGLBuffer warnings...)
QVTKRWIBase = "QWidget"
and you can also set the python Qt
binding by setting PyQtImpl
to one of ["PySide6", "PyQt6", "PyQt5", "PySide2", "PyQt4", "PySide"]
:
# PyQtImpl can be set by the user
PyQtImpl = None
QVTKRenderWindowInteractor.py then pulls in the modified information
# Check whether a specific PyQt implementation was chosen
try:
import vtkmodules.qt
PyQtImpl = vtkmodules.qt.PyQtImpl
except ImportError:
pass
# Check whether a specific QVTKRenderWindowInteractor base
# class was chosen, can be set to "QGLWidget" in
# PyQt implementation version lower than Qt6,
# or "QOpenGLWidget" in Pyside6 and PyQt6
QVTKRWIBase = "QWidget"
try:
import vtkmodules.qt
QVTKRWIBase = vtkmodules.qt.QVTKRWIBase
except ImportError:
pass
This situation isn't ideal because if the user changes or updates versions of VTK
, manual changes in the __init__.py
get overridden, so the changes would have to be remade. It would be much nicer if the user were to set this dynamically in their code:
import vtkmodules.qt
vtkmodules.qt.PyQtImpl = 'PySide6'
vtkmodules.qt.QVTKRWIBase = 'QOpenGLWidget'
from vtkmodules.qt.QVTKRenderWindowInteractor import QVTKRenderWindowInteractor
I think the above should be added to the pyvistaqt
documentation, since most users won't know to manually modify vtkmodules/qt/__init__.py
. However, see below (I think QWidget
should be the default).
From the What's New in Qt4, Qt4
split QWidget
's WFlags
into Qt::WindowFlags
and Qt::WidgetAttribute
flags and introduced WA_PaintOnScreen
for backwards-compatibility. In Qt4
, all widgets are double-buffered, so the WA_PaintOnScreen
allowed setting a widget to use single buffering.
Even though the raster paint engine is the primary paint engine for QtWidget
-based classes on Windows, X11, and macOS, I don't that there's necessarily a huge performance difference suing QWidget
vs QOpenGLWidget
.
A good reference w.r.t. using the QVTKOpenGLWidget
variants is this discourse discussion:
How to decide between QVTKOpenGL{Native}Widget?
We could try to implement them using the developer tips from here:
@prabhuramachandran I realized my fix isn't really a fix: the errors occur when QVTKRenderWindowInteractor
subclasses from anything other than QWidget
.
On Windows, X11, and MacOS, with Qt>5.4
the primary paint engine for QWidget
-based classes is the raster paint engine. When the raster engine is used, Windows and macOS ignore WA_PaintOnScreen
, but since we call winId
(which works on all platforms), we get a native widget with the raster engine, so returning None
from QWidget::paintEngine()
doesn't cause an error.
Using an opengl paint engine, however, causes a problem. 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. However, single buffering will not work with QOpenGLWidgets
as the Qt docs clearly state:
QOpenGLWidget
always renders offscreen, using framebuffer objects.QGLWidget
on the other hand uses a native window and surface.
Hence QOpenGLWidget
is always going to be double-buffered.
The QVTKOpenGL widgets were introduced to work with Qt's QOpenGLWidget
, but these have not been ported to Python VTK (i.e. vtkmodules
).
In PyQt5>5.4
and all of PyQt6
(and their PySide
equivalents), the QGL
classes are gone and replaced by the QOpenGL
classes. So, if we want to support the latest versions of PyQt
and PySide
, let users fix rendering glitches on their hardware (esp. non-desktop versions) we need DLL's for the QVTKOpenGL widgets ported to vtkmodules
.
Alternatively, if those DLL's can't be ported, we could try to implement these classes using the Python Wrappers developer notes.
@prabhuramachandran @wmvanvliet @larsoner I have submitted MR 9443 on VTK
to attempt to solve this issue. Would you please kindly review the MR? (The VTK
team has asked I bring in reviewers from mayavi
and pyvista
).
Thanks in advance!
@prabhuramachandran Any chance you would be able to review MR 9443 this weekend?
When setting
QVTKRWIBase = "QGLWidget"
invtkmodules/qt/__init__.py
to work around rendering glitches, no graphics are being shown and the following error is generated:In
tvtk/pyface/ui/qt4/QVTKRenderWindowInteractor.py
, there is the following construct:Removing the
try/catch
black to force using the deprecatedQGLWidget
instead of the more modernQOpenGLWidget
fixes the problem and everything runs smoothly. However, we should of course useQOpenGLWidget
. But there must be some difference between the two that is causing the error.I tested this on multiple devices with different types of video cards, I consistently get the error every time.
@larsoner