[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