[PATCH] Get rid of QPainter warnings
Germain Garand
germain at ebooksfrance.org
Wed Apr 2 00:43:08 BST 2008
Le mardi 1 avril 2008, Fredrik Höglund a écrit :
> My analysis of those warnings is that they're related to the shared
> painter optimization in Qt 4.4. I think what happens is that when khtml
> calls end() on the painter, Qt doesn't really end the painter, because
> the painter is actually shared by the whole widget hierarchy. When
> khtml calls begin() again on the same device, Qt gets confused.
>
> You'll see that if you set QT_NO_SHARED_PAINTER=1 before running
> Konqueror, you no longer see those warnings.
indeed, great findings!
I don't think it is caused exactly by the end()/begin() calls, since they are
not actually used (that's the optimisation I disabled: the !buffered code
path in copyWidget is not used presently) but it is definetly some shared
painter mess up in QWidget::render.
QWidget::render is actually given a buffer pixmap as target device:
if (buffered) { // always true
[..]
pm = PaintBuffer::grab(widget->size());
[..]
d = pm;
[..]
}
[..]
widget->render( d, (buffered ? QPoint(0,0) : thePoint) + r.topLeft(), r);
>
> Germain: It's occurred to me that the problem with embedding a QWidget
> in a QGraphicsView is pretty much the same problem as with embedding
> widgets in khtml. In other words having the widgets respect the Z order
> when they're fully or partially obscured by something that isn't a widget.
> The main difference is that khtml doesn't need to be able to apply an
> arbitrary perspective transformation matrix to the widget.
precisely.
>
> But I'm wondering if the khtml code can't be improved by taking advantage
> of the infrastructure Trolltech has added to do this in QGraphicsView.
> I'm not suggesting we turn khtml into a QGraphicsView, but rather use
> the new widget attributes such as Qt::WA_DontShowOnScreen.
that's an excellent idea indeed.
I would hope that it would also let us stop abusing Qt::WA_WState_InPaintEvent
(as off-screen widget don't generate paint events when they are update()'d, I
used this flag to have any spontaneous update() being bounced back as an
UpdateLater event, thus allowing KHTMLView's observer to now what to update)
I don't have time to investigate that right now, but definetly will in the
coming monthes.
Greetings,
Germain
More information about the kfm-devel
mailing list