Fwd: khtml rendering performance

[Germain Garand]

Le Jeudi 02 Décembre 2004 21:07, Leo Savernik a écrit :
> Am Donnerstag, 2. Dezember 2004 18:49 schrieb Luciano Montanaro:
> > KHTML renders the the full page again each time some elements of it are
> > dynamically changed. This makes the machine crawl when, for example, a
> > clock as the one you can find at the link below is running in the
> > background.
>
> Known problem. Do you volunteer and merge the incremental repaint fixes
> from Safari?
>

mmh... I'm not yet convinced it would be a good thing.
WebCore is doing it the complicated way and in some respects, incorrectly IMO.

It uses to store repaint rectangles and the associated objects in the view 
itself, which is awkward and can be wrong.
e.g. by the time it calculates the repaint rectangles, the layout isn't 
finished, so there's really nothing to guarantee that the stored rectangles 
are final (the object could very well clear a float, and thus be shifted by 
its parent, so the rectangle would become bogus).

So, I'd rather propose a simpler implementation, that does not try to be too 
clever (see attached), letting the Canvas handle the dirtying of it's 
children, and not trying to store any rectangle.

That makes the intermittent CPU hogging go down from 100% to 10% on
   http://www.virginradio.co.uk/thestation/listen/streams.html
and about 38% on 
   http://www.dnevnik.bg/ which has other fancy stuff

What do you think?

Greetings,
Germain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defer_dirtying.diff
Type: text/x-diff
Size: 4347 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20041203/c62b482b/attachment.diff>