perf: SG-43585: Performance improvement of pyevaluate and pyexec

[bernie-laberge]

Credit: the viewport refactor at the heart of this PR is Cédrik Fuoco's work — moving the
RV viewport off QOpenGLWidget and onto a native QOpenGLWindow, and every knock-on change that
followed from it (context sharing, presentation/second-output, blocking overlay). The additional
commits here are the startup-ordering fix and documentation on top of that foundation.

Linked issues

No GitHub issue — tracked internally as SG-43585

Summarize your change.

After the Qt5 → Qt6 migration, JS ↔ Python web-panel bridge round-trips (pyevaluate / pyexec)
became slow whenever the JavaScript handler did real RV work such as clearSession() /
addSourceVerbose(). The bridge is delivered synchronously on the Qt main (GUI) thread, so any
redundant work RV does on that thread directly delays queued bridge calls.

Nothing about the bridge itself changed between Qt5 and Qt6 — QWebChannel, QtWebEngine, the
2-second askForRedraw() settle window and the 120 Hz heartbeat are all identical in both trees.
The one difference that matters is that QGLWidget was removed in Qt6, so the viewport became a
QOpenGLWidget. A QOpenGLWidget renders to an offscreen FBO and forces the whole top-level window
onto the OpenGL/RHI path, so every viewport repaint recomposites every widget in the window —
toolbars, docks, and the web panel — and presents the whole window. Same redundant redraws as Qt5,
roughly 10× the cost each, on exactly the thread the bridge needs.

This PR gives the viewport its own surface back: it now renders as a native QOpenGLWindow (new
GLWindow) embedded via QWidget::createWindowContainer. GLView becomes a plain QWidget facade
that delegates to it, so nothing outside RvCommon had to change.

Measured with the mre_plugin reproducer at a 150 ms interactive cadence (playback + real session
work in the handler):

Platform	Before	After
Linux (X11)	~15 ms	~1.4 ms	~10×
macOS	~7 ms	~0.9 ms	~8×
Windows	—	not measured

Describe the reason for the change.

A user reported that web-panel bridge calls became slow after the Qt6 migration. A three-way
isolation on Linux at interactive cadence pinned the cause to the surface, not the bridge and not
the repaint count:

Tree	What it is	mean latency
A (main)	QOpenGLWidget viewport	~15 ms
B	one-line heartbeat fix, still QOpenGLWidget	~15 ms
C (this PR)	native GL window + ordering fix	~1.4 ms

B − A ≈ 0, C − B ≈ −13.6 ms. The entire win is the surface change. A separate one-line
heartbeat fix (isUpdating() → isPlaying() || m_wantsRedraw) was evaluated and deliberately
not included here: it measured no benefit at interactive cadence, and it risks stopping
animation for anything that redraws during the settle window without calling askForRedraw() each
frame (cache/buffer progress indicators first). It can land separately on its own merits.

Describe what you have tested and on which operating system.

Windows (Release) — the viewport refactor itself: flat bridge latency under playback spam, all
web panels render docked, and viewport / events / drag-and-drop / annotations / presentation /
blocking-overlay all work.

Linux (X11) — launches cleanly, docked QWebEngineView works, media loads; bridge latency
measured 15 → 1.4 ms at 150 ms cadence.

macOS — launches cleanly, session init/teardown and media load work, docked QWebEngineView
works; bridge latency measured 7 → 0.9 ms.

Not yet covered — please weigh this in review:

• Windows has not been re-exercised since the startup-ordering commit, which changes launch
  ordering. It is also the platform whose synchronous initializeGL() masked both original startup
  bugs, so it is the most likely place for a surprise.
• macOS feature sweep and an HDPI / mixed-DPI multi-monitor pass are still pending.
• Presentation mode / second output was reworked to share a context explicitly and wants an
  end-to-end test on real multi-display hardware.

Add a list of changes, and note any that might need special attention during the review.

The refactor

• New GLWindow : QOpenGLWindow (GLWindow.h/.cpp, 372 new lines) — takes over initializeGL,
  resizeGL, paintGL, event, eventProcessingTimeout, absolutePosition, readPixels,
  stopProcessingEvents, firstPaintCompleted, devicePixelRatioF.
• GLView becomes a plain QWidget facade (−748 lines) — keeps sizeHint,
  minimumSizeHint, rvGLFormat, setContentSize; everything else forwards to m_glWindow. Its
  public surface is unchanged, so no caller outside RvCommon was touched.
• QTGLVideoDevice gains a window-backed path — two constructors, m_view XOR m_window, plus
  backing-agnostic glShareContext() / glSurfaceFormat() so callers no longer care which backing
  the control view uses.

Knock-on changes forced by the new surface — these are the parts most worth a careful read:

1. Qt::AA_ShareOpenGLContexts is now set before the QApplication (a documented QtWebEngine
   requirement). It also lets second-output and upload-worker GL surfaces share with the viewport
   without an ordering-sensitive setShareContext(), and retires a null-context dereference that
   crashed with Multithread GPU Upload enabled.
2. Presentation / second output — DesktopVideoDevice::open() no longer dereferences the control
   device's (now-null) QOpenGLWidget; ScreenView shares a QOpenGLContext through the new
   accessors.
3. UI blocking overlay reworked from a raster child widget into a frameless translucent
   top-level window. A native window renders above sibling raster widgets regardless of raise()
   order, so the old overlay could no longer dim the viewport.

Startup-ordering fix — RvDocument::initializeSession() used to run from
GLWindow::initializeGL(), so constructing the RvSession (and loading every package, which runs Mu
and Python) depended on when Qt delivered the viewport's first expose. The platforms disagree on
that: on macOS a QOpenGLWindow has no GL context until first exposed, so the session was built with
no current context and aborted in IPCore::Shader::initGLSLVersion(); on Linux/X11 show() is
async, so doc->session() returned null a few lines later and RV segfaulted in
Session::queryAndStoreGLInfo() with this == nullptr (confirmed under gdb); Windows appeared to
escape both because initializeGL() fires synchronously during construction there. Now
RvApplication::newSessionFromFiles() calls initializeSession() right after show(), and
initializeSession() makes the viewport context current itself. There is a single RvDocument
creation site, so that is the whole ordering, and initializeGL() no longer calls back into the
document.

QT_QUICK_BACKEND=software — deliberately asymmetric, please do not "clean this up":

• src/bin/apps/rv/main.cpp (Windows, Linux) — the block is dropped. It was already commented out,
  and Linux has since confirmed the setting is not needed.
• src/bin/nsapps/RV/main.cpp (macOS) — the setting stays and is load bearing. The viewport
  window is a QObject child of the top-level's QWidgetWindow; with the hardware Qt Quick backend,
  adding a QWebEngineView makes Qt destroy and recreate that native subtree, deleting the embedded
  window rather than reparenting it, after which Qt's own QWindowContainer dereferences the window
  it lost. Measured with the four-line reproducer now quoted in the comment: software survives 2/2,
  hardware crashes 2/2. The cost is that macOS web panels composite in software — macOS gets the
  cheap-viewport half of this win, not the hardware-web-panel half.

Also in the diff: crashpad's MSVC toolset is pinned to the parent build (fixes an LNK2019).

Known risk areas for review

• Native-window vs widget stacking. Anything that assumed it could draw over the viewport as a
  sibling widget needs checking — the blocking overlay already had to become a top-level window.
  Annotations, HUD-style widgets and full-screen transitions are the places to look.
• HDPI. Coordinate translation now goes through the container widget while rendering goes through
  the window, so devicePixelRatio paths deserve a mixed-DPI pass.
• Windows startup ordering, per the testing section above.

If possible, provide screenshots.

A slide deck walking through the refactor class by class is attached: SG-43585_viewport_refactor.pptx.

SG-43585_viewport_refactor.pptx