views:

540

answers:

2

I'd like to know what happens exactly when I call a QWidget's update() method.
Here is the documentation:

http://doc.trolltech.com/4.5/qwidget.html#update

This function does not cause an immediate repaint; instead it schedules a paint event for processing when Qt returns to the main event loop. This permits Qt to optimize for more speed and less flicker than a call to repaint() does.

I see from the Qt source code that a QUpdateLaterEvent is created and post with type QEvent::UpdateLater

In this part of the documentation http://doc.trolltech.com/4.5-snapshot/qevent.html

QEvent::UpdateLater: The widget should be queued to be repainted at a later time.

What does 'later time' mean?
Are my all emited queued signals and the events in the event queue processed before the paint?

Thanks,
Gabor

+3  A: 

After checking QWidget::update() source code I've found it calls this method in src/gui/kernel/qwidget.cpp:9544 :

void QWidget::update(const QRect &rect)
{
    if (!isVisible() || !updatesEnabled() || rect.isEmpty())
        return;

    if (testAttribute(Qt::WA_WState_InPaintEvent)) {
        QApplication::postEvent(this, new QUpdateLaterEvent(rect));
        return;
    }

    if (hasBackingStoreSupport()) {
        QTLWExtra *tlwExtra = window()->d_func()->maybeTopData();
        if (tlwExtra && !tlwExtra->inTopLevelResize && tlwExtra->backingStore)
            tlwExtra->backingStore->markDirty(rect, this);
    } else {
        d_func()->repaint_sys(rect);
    }
}

As you can see the QUpdateLaterEvent is only posted if the update() is already called from inside a paintEvent() method.

You can also check QWidget::repaint(const QRect &rect) source on line 9456 - it lacks testAttribute(Qt::WA_WState_InPaintEvent) check.

EDIT

The QUpdateLaterEvent is posted as a Qt::NormalEventPriority event, so it gets processed after all other normal priority events (see src/corelib/kernel/qcoreapplication.cpp:971 and :1003). You might also want to look into compressEvent code, I haven't checked that.

So to finally answer the question: the QUpdateLaterEvent is processed after other high and normal priority events that were in queue before it was posted.

frgtn
Thanks, but I have seen this function before. But I'd like to know what happens with the posted event. What is the priority of the event? What other events are processed before/after this event.
Vereb
What about the queued signals that were emited in another thread to the main thread? Are the signals processed before the events?
Vereb
Documentation is a bit ambiguous on this: couldn't quite make it out if the signals are queued on the sender's or the receiver's event loop.
frgtn
The painting is on the main thread and I emit non blocking queued signals from another thread to the main thread. So it is queued on the receiver's thread I guess.
Vereb
+1  A: 

Behavior is not documented == not guaranteed to stay the same between Qt versions. You shouldn't write code which depends on the ordering of paint events relative to other events.

Intransigent Parsnip