repainting

[Dirk Mueller]

Hi, 

I've looked into repainting scheduling handling again, and with the stuff in 
mind you did in your INCREMENTAL_REPAINT code, I've optimized it a little.  
Well, in most testcases I investigated the new code reduced overall (khtml+X 
server) cpu footprint by about 60%. 

The logic is as follows: 

collect damage rectangles in a QRegion, which automatically collapses them and 
sorts them in a y/x layout fashion for us, for about 20ms. Then, we go 
through what we collected so far, and try to find subsets of that damage 
region that result in minum of bounding rect sizes and minimum of vertical 
stripes (since every vertical stripe to paint has the huge overhead of a 
complete rendertree traversal). 

With some guessing and trial and error, I ended up with this code: 


    QMemArray<QRect> rects = d->updateRegion.rects();
    QRegion updateRegion;
    if ( rects.size() )
        updateRegion = rects[0];

    for ( unsigned i = 1; i < rects.size(); ++i ) {
        QRect obR = updateRegion.boundingRect();
        QRegion newRegion = updateRegion.unite(rects[i]);
        if (2*newRegion.boundingRect().height() > 3*obR.height() )
        {
            repaintContents( obR, false );
            updateRegion = rects[i];
        }
        else
            updateRegion = newRegion;
    }

    if ( !updateRegion.isNull() )
        repaintContents( updateRegion.boundingRect(), false );

    d->updateRegion = QRegion();


which seems to work pretty well. In general painting "additional pixels" has 
fairly low time overhead here, probably because of all the graphics card 
hardware acceleration. The cpu overhead of additional rendertree traversals 
is much higher, and actually causes slower repaint behaviour, since the cpu 
can't keep up on complex pages with the graphics card speed. 

Please let me know what you think of it. 


Dirk