faster paint tree traversal

Dirk Mueller mueller at kde.org
Wed Feb 11 06:14:54 CET 2004


On Wednesday 11 February 2004 05:55, David Hyatt wrote:

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

Its really straightforward, besides RenderTable being a bit hairy. I'll attach 
my diff for RenderTableCell and RenderTable::paint() as reference, they work 
fine for me this way (not extensively tested yet though). 

> BTW, isRoot was slow for us too, because of documentElement() being
> slow.

right, and the whole stuff not being inline. Is there any reason for doing it 
so complicated anyway? We don't support multiple rendering nodes under the 
canvas node anyway, so isRoot() should be equivalent to "parent() && 
parent()->isCanvas()". Right?

> 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.

Hmm, thats a great idea. On the other side, I'd really like to get rid of it.. 
How about setting "overhangingContents()" for the "root" element? I don't 
think this has any other side effect besides doing exactly what we want here. 
And overhangingContents is just a bitflag in renderobject, so the fastest 
possible test, even faster than a pointer comparison in PaintInfo.

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

eek.. and when its the DTD ? :) IMHO thats too dangerous. 

> 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.)

can you name an example testcase which you fail?

> What do you think?

Not that much without knowing what the problems are. In general it would be 
nice if we could find a solution that both sides can use. 


Dirk


More information about the Khtml-devel mailing list