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

[cedrik-fuoco-adsk]

SG-43585: Performance improvement of pyevaluate and pyexec

Linked issues

none

Summarize your change.

Two independent performance fixes for JS→Python web-panel bridge latency in Qt6:

• Skip the redundant view-edit-mode deactivate→reactivate churn when a view change doesn't actually change the edit mode.

• Stop a static (non-playback) askForRedraw() from opening the 2-second continuous-repaint "settle window".

Describe the reason for the change.

After the Qt5→Qt6 migration, JS<>Python web-panel bridge round-trips (pyevaluate / pyexec) became slow and grew unbounded whenever the handler did RV work such as clearSession() / addSourceVerbose(). The bridge is synchronous on the Qt main (GUI) thread, so any redundant work RV does on that thread directly delays delivery of queued bridge calls. Two sources of avoidable GUI-thread work were the root cause:

• Redundant edit-mode churn. clearSession() sets the default view twice with force=true. Each before/after view-change event toggled the same view edit mode off and back on (up to 4× per clear), rebuilding menus and event tables for no net change.

• Settle-window repaint storm. A static askForRedraw() started a 2-second window that kept isUpdating() true, so the ~120 Hz heartbeat kept repainting for ~2 s even after the single needed frame had been drawn. In Qt5 each QGLWidget swapped its own back buffer cheaply, so this was nearly free; in Qt6 every redraw forces a full-window QOpenGLWidget recomposite + present, so the window saturated the GUI thread long after any real drawing was needed.

First commit cuts the time it takes to do a clearSession.
Second commit makes a static redraw cost a single frame instead of ~2 s of continuous composites.

Describe what you have tested and on which operating system.

Windows

[cedrik-fuoco-adsk]

While this commit (6879c31) seems promising in fixing the issue in my test, it's a shift in how GLView works, and it's experimental. I only tested it on Windows. @bernie-laberge @eloisebrosseau

From my observation and testing, the root cause seems to be the following:

GLView was a QOpenGLWidget, which renders into an offscreen FBO that the top-level QMainWindow must re-composite every frame (~90 ms). That composite runs on the same GUI event loop that delivers QWebChannel messages, so at ~120Hz the bridge reply queues behind an ever-growing backlog of presents.

The fix:
Make the viewport a native QOpenGLWindow (new GLWindow) embedded via QWidget::createWindowContainer. It presents on its own surface via swapBuffers, decoupled from the main window's paint. The GUI thread stays free to dispatch QWebChannel promptly.

Why Qt5 didn't have this problem

Before the Qt6 port, RV's viewport was a QGLWidget, which owned its own native window and GL surface and presented (swapBuffers) directly to the screen. Essentially the same model we're returning to with QOpenGLWindow. There was no offscreen FBO and no full-window re-composite, so the per-frame present never ran on the shared GUI-thread composite path and never serialized against QWebChannel delivery. Playback and the JS bridge ran independently.

QGLWidget was removed in Qt6, so the port replaced it with QOpenGLWidget. Unlike its predecessor, QOpenGLWidget renders into an offscreen FBO that the top-level QMainWindow must composite into its backing store every frame on the GUI thread (~90 ms). That new per-frame composite is exactly what starves the bridge during playback.