[Qt] multiple window/docking support

[tlambert03]

it looks like the call to winId() here in rendercanvas:

rendercanvas/rendercanvas/qt.py

Lines 255 to 275 in 5d73852

	def _get_surface_ids(self):
	if sys.platform.startswith("win") or sys.platform.startswith("darwin"):
	return {
	"window": int(self.winId()),
	}
	elif sys.platform.startswith("linux"):
	if False:
	# We fall back to XWayland, see _coreutils.py
	return {
	"platform": "wayland",
	"window": int(self.winId()),
	"display": int(get_alt_wayland_display()),
	}
	else:
	return {
	"platform": "x11",
	"window": int(self.winId()),
	"display": int(get_alt_x11_display()),
	}
	else:
	raise RuntimeError(f"Cannot get Qt surface info on {sys.platform}.")

causes problems with the dock widget system, such that when you drag them, they don't "go with you" ... It's hard to explain so here's a visual:

before adding pygfx canvas, when you click and drag a dock widget it goes with you:

Screen.Recording.2025-02-03.at.7.48.41.PM.mov

after adding pygfx canvas, it does indeed float... but then it "stays put" until you go back and click on it again

Untitled.mov

really not sure who should be "responsible" for this one (pygfx or the end user). But so far, I haven't yet been able to find a way to recover normal dock widget activity after having instantiated a QtRenderCanvas.

[almarklein]

Thanks for the report! I can indeed reproduce this with this minimal example. It does not even need a rendercanvas; creating a widget and calling winId() on it is enough to trigger the issue:

from PySide6 import QtWidgets, QtCore
# from rendercanvas.qt import QRenderWidget
# from rendercanvas.utils.cube import setup_drawing_sync


class Main(QtWidgets.QMainWindow):
    def __init__(self):
        super().__init__()
        self.resize(800, 600)

        # self.canvas = QRenderWidget( update_mode="continuous")
        # draw_frame = setup_drawing_sync(self.canvas)
        # self.canvas.request_draw(draw_frame)

        self.canvas = QtWidgets.QWidget()
        self.canvas.winId()

        self.dock1 = QtWidgets.QDockWidget("Dock 1", self)
        self.dock2 = QtWidgets.QDockWidget("Dock 2", self)
        self.dock3 = QtWidgets.QDockWidget("Dock 3", self)

        for dock in (self.dock1, self.dock2, self.dock3):
            dock.setFeatures(QtWidgets.QDockWidget.DockWidgetFeature.DockWidgetMovable)
            self.addDockWidget(QtCore.Qt.DockWidgetArea.LeftDockWidgetArea, dock)

        self.dock1.setWidget(QtWidgets.QPushButton("A button"))
        self.dock2.setWidget(QtWidgets.QPushButton("Another button"))
        self.dock3.setWidget(QtWidgets.QWidget())

        self.setCentralWidget(self.canvas)


app = QtWidgets.QApplication.instance()
if app is None:
    app = QtWidgets.QApplication()
m = Main()
m.show()
app.exec()

Not a huge problem, since users can still move the dockwidget, although its annoying.

I tested this on MacOS, are you aware of other platforms where this happens?

This looks like this bug report: https://bugreports.qt.io/browse/QTBUG-90976, and some others that it links to. They all seem closed though, so I'm not sure of the current status.

[tlambert03]

Also tested on macOS…. Haven’t tried others yet. Thanks for pasting the mre (sorry I should have pasted the little simple example I also made while testing)

[tlambert03]

Feel free to close this. I’m not sure how actionable it is from your side. I dont yet know enough about the underpinnings to know whether there could be a reasonable workaround to calling winId().

[Korijn]

This looks like this bug report: https://bugreports.qt.io/browse/QTBUG-90976, and some others that it links to. They all seem closed though, so I'm not sure of the current status.

This bug (and the related bugs) are all from 2021 or older, I believe, and they seem to relate to Qt 5 as well. There might be a regression in Qt 6 now.

@tlambert03 I think the best action you could take is create an account and file a bug report with the PySide developers here: https://bugreports.qt.io/projects/PYSIDE/issues/

You can share Almar's MRE with them.

I've done this before and they were quite responsive and eager to help!

[tlambert03]

Yeah I’ve filed bugs there as well, (can’t say it’s always met with eagerness though, so generally look for workarounds first). I think it’s lower than pyside/shiboken though, as it happens with pyqt too

[Korijn]

Well, in that case, I hope we get lucky :)

[almarklein]

... whether there could be a reasonable workaround to calling winId().

I was going to suggest that you set QRenderWidget(..., present_method="bitmap"), which will render to an offscreen texture, download it, and pass the bitmap to qt. However, as it is now, winId() is called regardless of the present_method. This is easy to fix though, and that would provide a route to avoid this issue. However, it will be at the cost of performance, which may be noticeable if the canvas size is large.

Other than that, if we want to render to the portion of the screen for that Qt widget, we really need that winid :)

[tlambert03]

fwiw, it doesn't seem to affect windows.

[tlambert03]

Actually, I think the issue of calling winId is a bigger deal than just dock widgets on macos. I can say that I've noticed a lot of weird little bugs over the past few months. There was this issue of dragging dock windows on macos (which we just decided to live with since macos wasn't our immediate target for this project). Then there is this issue in ndv of weird positioning of a dropdown: which doesn't happen with vispy, and only happens once we let rendercanvas call winId. I'm now also seeing pygfx play poorly with qt-advanced-docking-system in pymmcore-plus/pymmcore-gui#51 ... there too, things are fine up until i create a pygfx canvas with rendercanvas... after which all rendering gets wonky (title bars are cut off and resizing leads to glitches).

So, for us at the moment, this issue is creeping into a lot of little annoying bugs, leaving us trying to determine whether it's worth pursuing one of those workarounds that @almarklein proposed above, or, unfortunately, possible not going full steam into pygfx as I had proposed in pyapp-kit/ndv#128.

I am unfortunately pretty useless in this at the moment, since I don't yet understand the need for, and implications of, winId. But just wanted to bump this now-closed issue and say that it's still a rather big issue for us

[tlambert03]

one question @almarklein... since vispy doesn't seem to have this issue, I went back to see what was done there. I see that the the EGL-backed canvas does use winId... but the "regular" CanvasBackendDesktop does not:

        if QT5_NEW_API or PYSIDE6_API or PYQT6_API:
            # Qt5 >= 5.4.0 - sharing is automatic
            QGLWidget.__init__(self, p.parent, hint)

            # Need to create an offscreen surface so we can get GL parameters
            # without opening/showing the Widget. PyQt5 >= 5.4 will create the
            # valid context later when the widget is shown.
            self._secondary_context = QtGui.QOpenGLContext()
            self._secondary_context.setShareContext(self.context())
            self._secondary_context.setFormat(glformat)
            self._secondary_context.create()

            self._surface = QtGui.QOffscreenSurface()
            self._surface.setFormat(glformat)
            self._surface.create()
            self._secondary_context.makeCurrent(self._surface)

is that code above similar in spirit to what you were describing in #55 (comment). that is, does it suffer from the same performance hit you'd expect with present_method="bitmap"? Or, does it actually benefit in this case from direct support of OpenGL by qt?

Either way, it would indeed be great if we had an option here, using rendercanvas and pygfx, to completely avoid using winId