Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When does a Qt widget get a paintEvent?

Tags:

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?

like image 523
sashoalm Avatar asked Jul 25 '12 08:07

sashoalm


People also ask

What is Paintevent in Qt?

Paint events are sent to widgets that need to update themselves, for instance when part of a widget is exposed because a covering widget was moved. The event contains a region() that needs to be updated, and a rect() that is the bounding rectangle of that region.

What is QWidget in Qt?

Widgets are the primary elements for creating user interfaces in Qt. Widgets can display data and status information, receive user input, and provide a container for other widgets that should be grouped together. A widget that is not embedded in a parent widget is called a window.

What is QWidget * parent?

The tree-like organization of QWidgets (and in fact of any QObjects ) is part of the memory management strategy used within the Qt-Framework. Assigning a QObject to a parent means that ownership of the child object is transferred to the parent object. If the parent is deleted, all its children are also deleted.


1 Answers

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.

like image 81
Cody Gray Avatar answered Oct 14 '22 02:10

Cody Gray