Question

I am wondering in which cases does a widget receive its paint event, and how does it vary with the OS.

Qt documentation for paintEvent says only

A paint event is a request to repaint all or part of a widget. It can happen for one of the following reasons:

repaint() or update() was invoked,

the widget was obscured and has now been uncovered, or

many other reasons.

So far, I’ve put some traces in the paintEvent,

void Widget::paintEvent(QPaintEvent *e)
{
    static int count = 0;
    qDebug("paintEvent, %d", count++);
}

and this is what I’ve found out (on Windows 7 at least):

The paintEvent is called when the widget loses/gains focus. The paint event is not called when another widget passes over our widget. I don’t know if that’s because of Windows 7 compositing. The paintEvent is also called when a minimized window is restored. The paintEvent is called when resizing.

So is the behaviour dependent on the OS?

Answer 1

Yes, in the sense that you describe, it’s dependent upon the operating system.

The Desktop Window Manager (DWM), found in Windows Vista and 7, the doohickey that is responsible for desktop composition, the Aero glass effect, and all kinds of other eye candy, works a bit differently than the model used in previous versions of Windows. As you suspect, it caches the bitmaps for your windows, even when they are not visible because they’re obscured by another window. That means it doesn’t need you to repaint them (and thus it doesn’t raise a paint event) because it can just blit them from the cached bitmap. Not only is this a potential optimization over having each application redraw itself, it also allows the DWM to implement things like Aero Flip, for which it uses its cached bitmap.

The exception to this is as it has always been for, say, the CS_SAVEBITS class style. If the bitmap that the DWM has cached has become invalidated (e.g., because your window image has changed), it will discard it and ask you to redraw the window.

Test this theory by turning off DWM composition (switching to the “Windows Classic” theme), and then obscuring your window to see if you receive a paint event. You should, just like you did in all previous versions of Windows.

But the larger point is that you should not rely on receiving paint events in any particular order. The only thing you should assume about paint events is that you’ll receive one when the operating system needs you to repaint your window. Otherwise, it won’t bother you. I’m sure that’s why the documentation is content with being vague on this point, beyond possible technical constraints.

This is why logic should not go inside of the paint event handler. The only thing that method should be responsible for is repainting the window by its current state. That state needs to saved elsewhere. This rule is also commutative: you should not do any painting outside of the paint event handler.

Of course, you can always force a paint event to be raised by invalidating your window (I’m sure Qt has an invalidate or refresh method for this, check the documentation), but that still doesn’t mean it’s a good pattern to place application logic in the method that handles this event.