Обязательно ли Qt :: paintEvent быть реентерабельным?

не делай этого. просто положите его в стек, чтобы при уничтожении в деструкторе он автоматически выполнял отрисовку.

void MyWidget::paintEvent(QPaintEvent *event)
{
    QPainter painter(this);
    // use painter
    ...
    // paint object automatically closes and paint on desctruction
}

Если вы пытаетесь избежать передачи виджета рисовальщика нескольким вызовам подпрограмм, вы, вероятно, можете обойтись указателем на рисовальщика в качестве переменной класса. Как уже упоминалось, вы все равно должны создавать / уничтожать его в функции paintEvent. Лично я, вероятно, просто передал бы его вспомогательным функциям, но вы могли бы сделать это и так.

Кроме того, я не уверен, как ваш вопрос связан с повторным входом. Вся отрисовка элементов пользовательского интерфейса должна выполняться только в потоке пользовательского интерфейса, если у вас несколько потоков. Вы можете рисовать изображение в другом потоке, но в этом случае вы, вероятно, захотите рисовать это изображение только в этом потоке, а не в нескольких потоках. В любом случае, я не думаю, что у вас возникнут проблемы с повторным входом в функциях Qt, которые вы вызывали бы у художника, пока вы соблюдаете эти условия.

Новый anser для более конкретного решения проблемы повторного входа ...

данатель оставил следующий комментарий к это сообщение (частично):

By reentrancy I mean this specific situation: 1) paintEvent handler saves a QPainter to a class variable. 2) paintEvent handler calls subroutines to draw something 3) one of the subroutines calls a Qt method 4) this Qt method generates another paintEvent recursively

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

В качестве примера давайте проследим ваши шаги и рассмотрим их более подробно.

1. Foo::paintEvent() обработчик создает QPainter и устанавливает Foo::m_painter_p у него.
2. Foo::paintEvent() звонки Foo::paintAntarticaFlag().
3. Foo::paintAntarticaFlag(): а) использует Foo::m_painter_p, затем б) вызывает то, что вызывает Foo::update(), затем в) использует еще немного Foo::m_painter_p.
4. Foo::update(), который на самом деле является методом Qt, генерирует событие paintEvent для Foo.

Вышеупомянутая последовательность подходит, поскольку обновление создает мероприятие, что означает отложенную обработку. Если вместо этого вы вызовете Foo :: repaint (), это вызовет немедленную рекурсию в Foo :: paintEvent (), что либо вызовет прерывание Qt, потому что вы создаете более 1 рисовальщика для одного и того же объекта, либо ваша программа прервется потому что в конце концов (вы знаете, за несколько сотен миллисекунд) стек уничтожил.

Если вы выполняете несколько потоков и просто хотите вызвать перерисовку, вы все равно можете сделать это из другого потока, поскольку он просто поместит событие paintEvent в очередь, чтобы его обработал соответствующий поток в нужное время. Если вы выполняете несколько потоков и хотите рисовать эти флаги с помощью одного и того же рисовальщика, не надо. Только не надо. В этом случае вы можете рассмотреть возможность рисования каждого флага на общем изображении и рисования этого изображения там, где вы сейчас используете QPainter.