У меня есть приложение, которое интенсивно использует pyqtraph в реальном времени в нескольких windows.
Чтобы обойти GIL Python и увязнуть в некоторых частях моего GUI, в то время как другие части выполняя большие gui нагрузки, я сделал различные части приложения их собственными исполняемыми процессами. Эти приложения регистрируют свои дескрипторы окон в главном приложении, которое создает QDockWidget вокруг окна.
class DockingWindowProxy(QtWidgets.QDockWidget):
def __init__(self, hwnd, *args, **kwargs):
super().__init__(*args, **kwargs)
self.window_wrapper = QtGui.QWindow.fromWinId(hwnd)
self.window_widget = QtWidgets.QWidget.createWindowContainer(self.window_wrapper)
self.setWindowTitle(view_setting.window_name)
self.setWidget(self.window_widget)
Это отлично работает с точки зрения поведения управления окнами, которое я хочу для всех приложений. , когда есть большая GUI нагрузка в клиентском окне может привести к тому, что все приложение оболочки перестанет отвечать , и нагрузка клиента также будет хуже, когда она вложена как таковая.
Согласно https://www.qt.io/blog/2013/02/19/introducing-qwidgetcreatewindowcontainer The rendering of the window happens directly in the window without any interference from the widgets, resulting in optimal performance.
и что это дает !? Почему на производительность DockingWindowProxy влияют операции в обернутом hwnd?