I'm using Qt5.6, I have QWidget graphic objects rendered and when other graphics are rendered in front of others this seems to trigger updates of the graphics under the graphics in front.
This creates overhead, I would like to determine if the graphic behind is completely obscured by the graphic in front and if so, then it should abort the paint event.
I thought this would be automatic and done as part of the internals of Qt, but it seems not.
Each widget's paint event is comes from the widget compositor, once the compositor determines that a widget should be repainted. There's no way to abort it: if the event arrives, it means that the widget must paint, or else you'll get visually undefined results.
By default, widgets can be transparent, and the widget compositor has to paint the entire stack of widgets in back-to-front order to compose them.
Any widget that is not transparent should have the Qt::WA_OpaquePaintEvent attribute set. This will inform the widget compositor that any widgets completely hidden behind the widget don't have to be painted. Ensure that you paint every pixel of your widget!
Related
We have big QT project where painting procedure often doesn't follow the rule that it should be done in overridden paintEvent method. As result we have warnings about it: Painter not active etc... But all work fine and at first glance I don't see any problems. Could you explain should I worry about it or not? What is the price of the incorrect use of this functionality?
Paint event is sended to the window when it is should be updated, eg when it is shown or something else. For example if widget is covered by another window, and this windows is moved away, then widget should be updated. Common way is to paint on the pixmap and draw this pixmap on the widget in the paint event handler. Or you can update/repaint each time you need to repaint it.
You can use QPainter to draw on pixmap, printer and so on whenever you want, but to draw on windget it must be done in paintEvent.
I found mistake - it is happened when invalid pixmap(I have created pixmap with size 0x0) is used. I have add check on it and now all are okey.
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?
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.
I have a main window with some widgets on it, each needs its own graphic. I would like to use QPainter to draw shapes, lines, etc. on them, but only after a specific event, like the press of a button.
The problem is, if I just create a QPainter in any function, it won't work:
QPainter::setPen: Painter not active
The QPainter methods can only be called inside a paintEvent(QPaintEvent *) function! This raises the following problems:
I have to derive my custom classes for all the widgets I would like to paint on, so I can't use the Designer to place my widgets. This can get frustrating with a large number of widgets.
The widgets redraw themselves after each paint event of the window, like moving it around, or moving other windows in front of it. I do a lot of drawing in those widgets, so they will visibly blink in these cases.
Is there a better and simpler way to solve this? I started to think about just displaying images, and re-manufacturing those images only when the specific buttons are pressed. I doubt that it's the most elegant solution...
You can use custom widgets in the designer: Creating Custom Widgets for Qt Designer.
Qt Designer's plugin-based architecture allows user-defined and third party custom widgets to be edited just like you do with standard Qt widgets.
For your second question, one of the approaches is to create a QPixmap for each of your widgets. When your widget's appearance needs to be changed, you draw in that pixmap (using QPainter's constructor that takes a QPaintDevice - QPixmap is a QPaintDevice).
In your widget's paintEvent function, you simply fill your widget with that "cache" pixmap. This way, you only do the (potentially expensive) painting when it's actually necessary.
I want to render the video from my webcam into QWidget. I've set QWidget, as a parent to IVideoWindow. Here is the code:
m_iVideoWindow->put_Owner((OAHWND)widget_->winId());
m_iVideoWindow->put_WindowStyle(WS_CHILD | WS_CLIPCHILDREN);
m_iVideoWindow->put_Left(0);
m_iVideoWindow->put_Top(0);
widget_->setChild(m_iVideoWindow);
Also i've reimplemented QWidget's resize event, and so when it's resizing it also resizes the IVideoWindow. Everything works good, when the widget is not set to the QLayout. When is - it becomes blank. That is the problem.
I think when Qt draws its widgets, it doesn't redraw them unless it knows they need to be updated. I'm also unsure as to whether it passes on whatever redraw stuff windows requires, to the window you've assigned as a child of the widget.
When I embed my own windows in a Qt widget, I use http://qt.nokia.com/products/appdev/add-on-products/catalog/4/Windows/qtwinmigrate/, but that may not solve your problem, as I still have to use a QTimer to force an update of my window.
Let's say that I have an application frame, and I want to show a popup QCalendarWidget over on the right side of the frame. Normally, QT will clip the edges of the QCalendarWidget, cutting it in half and not displaying the rest, as it would be over the right side border.
Is there a way to work around this limitation without resorting to implementing a QDialog?
I want the widget to be visible outside the bounds of it's container.
If you'd show your Calendar, let's say, after a button click, as QDateTimeEditor does, it's contents will not be clipped, cause it do not belong to frame. It will be just a widget, that shows in a dialog manner. And maybe you should even place it in QDialog, that is modal and provides some convenience methods, rather then simple QWidget.
Btw, why don't you want to use QDatetimeEditor?