[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: kdelibs/khtml/html
From:       Lars Knoll <Lars.Knoll () mpi-hd ! mpg ! de>
Date:       2000-06-26 12:16:04
[Download RAW message or body]

On Mon, 26 Jun 2000, Peter Kelly wrote:

> The problem with this is that every time a DOM element gets changed or
> added, relayouting/repainting gets done which is slow if a script makes
> a lot of changes to the DOM (e.g. the DOM test suite, where it adds a
> line to the output for each test it does). The way I had it is very fast
> running the test suite, but slow if only one change is made to a small
> part of the page, e.g. rollovers :(

That's true. But the old way reparsed the whole style elements for all of
the page, reparsed all of the Images, and did a relayout of the whole page
afterwards. A simple image rollover (which is about 90% of the effects on
web pages) took on www.linuxtag.de about 2-3 seconds on my
machine. After my commit yesterday it works instantanious.

> What I was sort of half-way through implementing was a scheme where if a
> DOM element gets changed in some way, e.g. a child inserted/deleted or
> one of the display-affecting properties gets changed, then that element
> is marked as "changed", and after the script has finished executing the
> changes become visible. That way you could basically reconstruct an
> entire page in javascript, and have it update once at the end.
> 
> But I ran into trouble getting it to decide what parts of the page need
> updating - e.g. if you just change an image, or the colour of some text,
> you do not need to relayout the page (although some recalculating is
> needed in the appropriate rendering object), and then just the part of
> the window that was affected is updated.

Hmmm... We could do it in a way similar to the fast image updating Waldo
implemented in the image cache. Add all changed DOM elements to a
list. For these elements (and it's children) reparse the Style object
first without relayouting. Set the layouted flag to false for all
these objects. After that call updateSize() on all of them. Advantage: The
updateSize() call relayouts the part of the rendering tree that is
influenced by the change. This might already group together some of the
relayoutings (for example all images that are changed in one paragraph
will get relayouted together), so that some of the updateSize() calls will
rturn immediately, since layouting has already been done on them.

Does that sound reasonable?

Lars

> 
> CVS by knoll wrote:
> > kdelibs/khtml/html html_imageimpl.cpp,1.52,1.53
> > Author: knoll
> > CVSROOT: /home/kde
> > Sun Jun 25 13:48:48 UTC 2000
> > Update of /home/kde/kdelibs/khtml/html
> > cvs.kde.org hosted by sourceforge.net
> > 
> > Modified Files:
> >         html_imageimpl.cpp 
> > Log Message:
> > do not check the _whole_ document for changes after each jscript call,
> > but only the elements and children that actuall ygot changed.
> > Speeds up jscript calls by a factor of 10-100. The jscript code on
> > www.linuxtag.de is actually fast now... :-)
> 
> -- 
> Peter Kelly
> pmk@post.com
> 

-- 
Lars Knoll                                 knoll@mpi-hd.mpg.de
  PGP pub key [6DADF3D5]: finger knoll@pluto.mpi-hd.mpg.de 

[prev in list] [next in list] [prev in thread] [next in thread]