faster paint tree traversal

[David Hyatt]

I think this is a great optimization.  I'll merge it right now.  Wish 
me luck. :)

BTW, isRoot was slow for us too, because of documentElement() being 
slow.  I fixed this (or at least improved it) by making a faster 
documentElement() for HTMLDocument, but an even better fix might be to 
stash the root in this new PaintInfo struct.

ElementImpl* HTMLDocumentImpl::documentElement() const
{
     return static_cast<ElementImpl*>(_first);
}

While we're talking about painting and rects, one very big change we've 
been contemplating here is that we'd really like to switch the engine 
over to using floats instead of ints for positioning/painting.  (Cocoa 
is all float-based so we're having to put all these rounding hacks in 
when text rendering, we fail CSS tests that use subpixel positioning, 
e.g., Hixie's tests, etc.)

My thought was to possibly introduce a typedef, e.g., Pixel, that could 
be an int for you and a float for us, and then start switching the 
engine over to this unit.  We might also need typedefs for rects and 
points so that we could use a float-based rect/point where you used 
QRect/QPoint.

What do you think?
dave

On Feb 10, 2004, at 7:54 PM, Dirk Mueller wrote:

>
> Hi,
>
> from-the-micro-optimisation-dept.: The split into RenderObject::paint()
> and ::paintObject() is no longer useful, and since both are virtual 
> and have
> like 10 parameters (which are all pushed on the stack etc), this is a
> significant cpu cycle waster. At least on AMD Athlon CPU's the stack 
> pushes
> are terrible slow.
>
> so I went ahead and merged all the stuff we currently pass around into 
> a
> PaintInfo structure which is allocated once and then only passed by
> reference. Also, paintObject was merged into paint(), reducing 20% of 
> the
> virtual method calls (there is one, isRoot() in RenderBlock::paint() 
> that
> really hurts with over 30% of the total CPU time, but I didn't manage 
> to get
> rid of that one yet).
>
> The total patch is quite a few dozen kb, but its essentially just 
> fixing the
> compilation errors triggered by the appended patch.
>
> would this be something you'd be interested in merging? It doesn't 
> have that
> much of a user-noticeable speedup, but it certainly helps in some
> pathological cases (though we need something better for long documents 
> like
> the stuff on my todo list). It is in the ~ 3-5% speedup range.
>
>
> Dirk
> <fastpaint.diff>_______________________________________________
> Khtml-devel at kde.org
> https://mail.kde.org/mailman/listinfo/khtml-devel