Fwd: khtml rendering performance

[Germain Garand]

Le Vendredi 03 Décembre 2004 15:43, Allan Sandfeld Jensen a écrit :
> > What do you think?
>
> It sounds great if we can do it this simple.
>

As a matter of fact, this kept me busy for a while :)

Over the week, I investigated several ways of simply and generally telling 
where to stop repainting in the hierarchy of a given object, but really found 
nothing reliable.

I understand why WebCore choose a brute force approach and tracks/calculate 
the absolute position and rectangle of every single RenderObject, but I still 
questioned its value, for it has many drawbacks:
1) it is not yet reliable - e.g even the simple testcase attached as repaint 
problems (at least in Nokia's WebCore) and I didn't look for it.
2) it is expensive and slows down layout for little benefits as far as 
non-layered objects are concerned (more on that latter)
3) it is convoluted and as such difficult to evaluate/maintain in a 
deterministic way

eventually, I considered that the major problem we have is repaint performance 
on layered objects. Performance on normal flow repaint is generally not 
critical and may even be worsened by expensive calculations at layout time, 
since in most cases, changes will percolate down to the canvas anyway.

So I came up with attached implementation, which gets layered repaints right 
(which is easily deterministic) and simply proceed to dirty non-layered 
objects up to the closest block formatting context with non variable 
width/height.

As far as I can tell this fixes all real-world testcases I have, including 
tomshardware.com.
For a striking example, see e.g http://geocities.com/e6y/doom.html

Greetings,
Germain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20041211/04ad95d5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repaints.2.diff
Type: text/x-diff
Size: 23790 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20041211/04ad95d5/attachment.diff>