When a render-to-texture widget gets added to a widget hierarchy, the GUI thread becomes significantly throttled if one has constant repaints (for instance a progress bar)

I *suspect* this is due to the fact that we render the top-level window containing such widgets using 3D graphics APIs (OpenGL, Vulkan, etc.), and at the end of each flush we swap buffers and wait for that to complete (i.e. we block for vsync).

However this introduces massive latencies in the GUI thread.

A timer that wants to fire every few milliseconds will always miss the target, because the vsync is throttling it back. Similarly, any "event intensive" activity going on in the main thread (networking, chunked processing, ...) will take way longer than necessary.

I think that the the vsync needs to be made asynchronous by default, unless an explicit synchronous flush is requested (for instance someone called QWidget::repaint instead of update, in which case repaint must not return until the result is on the screen.)

You can find a minimal testcase here https://github.com/dangelog/quickwidget_blocks_the_event_loop

There's a timer that wants to keep a 1ms deadline. It can do that, but as soon as one adds a QQuickWidget, the timer gets delayed and syncs to the refresh rate.