Думаю "собственно рисованием" занимается обработчик события UpdateRequest. Это он вызывает paintEvent рекурсивно. Начиная с пятерки рисуется все в QImage (хотя это противоречит double-buffer). В конце обработчик вызывает нативный API для вывода на экран.

ОС посылает событие рисования (что выливается в UpdateRequest) в той нитке где создано QApplication (обычно главной). Просто вызвать UpdateRequest из др нитки может и можно (не проверял), но эффекта не имеет т.к. нет dirtyRegions - нужен сначала update, а он вызовет рисование в главной.

Это только один из возможных методов), нативно реализованный в Qt. Но внутри paintEvent можно только готовить данные для отрисовки кадра (менять атрибуты графических узлов сцены, готовить QImage, или вообще напрямую заполнять массивы в видеопамяти), а непосредственно отображением может заниматься отдельная сущность в отдельном потоке, совершенно никак не связанная ни с QWidget, ни с Qt. Порядок отрисовки зависит только от порядка графических узлов сцены, а частота кадров может никак и не зависеть от частоты вызовов paintEvent.

Вопрос был другой - Почему GUI в Qt всегда однопоточный. Сам процесс отображения не накладывает никаких ограничений на многопоточность GUI, а вот обеспечение правильного порядка обработки событий клавиатуры или мыши можно легко достигнуть с помощью ограничения однопоточности, да и за голыми указателями не нужно следить, и signal/slot в виде Direct соединений, и множество других небрежных плюшек. Изначально GUI было спроектировано таким образом, а далее ...


Это ограничение так сильно пронизывает Qt, что устранять его не целесообразно. Проще написать другой инструментарий.

Ну Тролли и поместили эту сущность в первую (главную) нитку процесса, а могли бы это же делать и в отдельной нитке. Именно эта сущность вызывает paintEvent, а готовить данные для отображения можно в других 100500 нитках.

И что получиться: венда/XWindow/...?
Большим достоинством Qt является то, что она может самостоятельно все отрисовать внутри некой области/top-level окна.

Да, применение ограничено, но есть. Не всегда удается вынести трудоемкую операцию в поток чтобы оставить UI свободным. В этом случае хорошо бы рисовать индикатор из "не UI" нитки. В этом году обсуждали.

Такой пример. Предположим необходимо отобразить два независимых GUI для управления устройством 1 и устройством 2 в одном. Существует также требование, что изменение состояние устройств должно быть отображено не позднее, чем 100 мс. При выполнении операции после нажатия на кнопку устройства 1 происходит подготовка данных порядка нескольких секунд. Что делать в однопоточной реализации GUI?

Естественное решение - формировать дополнительный поток (с соответствующими накладными расходами), обеспечивающий подготовку данных, или как-то использовать processEvents(). В многопоточном GUI в этом нет необходимости, так как отображение и реакция на события уже многопоточны (асинхронны).

Окна устройства 1 и устройства 2 могут перекрываться, как они будут обновляться на экране?
Окно устройства 1 обновляется 1 раз в 100 мс, окно устройства 2 обновляется 1 раз в 5 сек. Окно устройства 2 перекрывает на половину окно устройства 1. Как будет обновляться видимая часть окна устройства 1? Кто будет это контролировать?

Так вот этот самый рендерер и есть та самая сущность, которая однопоточно все отрисовывает. Про нее я вам и речь веду.
Если вы все отрисовки виджетов будете делать в других потоках на QImage, а в paintEvent просто рисовать полученный QImage на виджет, у вас получиться тот самый способ отрисовки, в котором Qt будет в роли рендерера.

Нет. Если элементы ветвей могут перекрываться - не может. А именно про это идет речь. Qt изначально умел рисовать все сам в frame buffer (что являлось его огромным плюсом), поэтому он сам является тем оконным композитором, который должен все отобразить. А это, для перекрывающихся виджетов, можно сделать только в один поток.

Когда вызывается paintEvent уже никто удалиться не может, потому что он может вызывается только из того самого рендерера, который должен быть в конечном итоге однопоточным. И именно он хранит иерархию отображаемых объектов.

Ok, с отображением вопросы отпали, остались с реакцией.
А что в Qt принципиально не позволяет сделать независимую реакцию элементов?