Details
-
Bug
-
Resolution: Out of scope
-
P2: Important
-
None
-
4.7.2, 4.8.4
-
Mac 10.6.8
Description
According to the documentation, QWidget::repaint should immediately call QWidget::paintEvent. (As opposed to QWidget::update, which puts a paint request on the event loop.) I am seeing this behavior on Windows, but on Mac, repaint appears to behave identically to update, i.e. it postpones the paint request until later.
#include <QtGui> class MyWidget : public QWidget { Q_OBJECT public slots: void DoRepaint() { QUuid id(QUuid::createUuid()); qDebug() << "Before repaint call" << id; repaint(); qDebug() << "After repaint call" << id; } protected: void paintEvent(QPaintEvent *event) { qDebug() << "paintEvent"; QWidget::paintEvent(event); } }; int main(int argc, char** argv) { QApplication app(argc, argv); MyWidget w; w.show(); QTimer timer; timer.connect(&timer, SIGNAL(timeout()), &w, SLOT(DoRepaint())); timer.start(1000); return app.exec(); } #include "main.moc"
The expected output (which happens on Windows and X11) would be:
Before repaint call "{2463f6a3-85b6-4ba8-b886-6e11910916e8}" paintEvent After repaint call "{2463f6a3-85b6-4ba8-b886-6e11910916e8}"
The actual output is:
Before repaint call "{2463f6a3-85b6-4ba8-b886-6e11910916e8}" After repaint call "{2463f6a3-85b6-4ba8-b886-6e11910916e8}" paintEvent
If I call qApp->processEvents() immediately after the repaint, then it works. But this obviously has other side-effects. In this sample application it is no big deal, but in my actual application I need an immediate repaint; an update will not do.
I am also seeing similar behavior in X11, although this sample code works there. I was not able to create a simple application that could reproduce the behavior, but X11 has a similar problem where you must call qApp->syncX() to get the repaint to take effect.
Attachments
Issue Links
- relates to
-
QTBUG-4453 repaint() does not work properly on Mac/Linux.
- Closed