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

List:       kde-core-devel
Subject:    Re: Khtml too slow ?
From:       Dirk Mueller <mueller () kde ! org>
Date:       2000-09-26 14:44:13
[Download RAW message or body]

On Die, 26 Sep 2000, Matt Koss wrote:

> > is that documentation local or remote?
> It's local. Obviously the display is slow, not the download :-)

Well, it makes a difference if you choose local or remote. http pages are
currently coming in with 4kb chunks, while local files are coming in in 32kb
chunks, which slows down the progressive display and makes konqueror hang
for a few parts of a second during loading. 32kb chunks are currently far
too big for khtml to swallow in a reasonable amount of time on a middle/low 
end machine. 

the second problem that pages with images are incredibly slow to load,
because the html loading has no precedence over image loading. This got even
worse as waba introduced a separate caching/loading mechanism for html files
which makes it even more difficult to block image loads until the loading of
the html file is "almost" finished. I wanted to address that but I won't be
able to do that in time for KDE2. 

> > and second: the "loading" is a bit slow because of the CSS stuff. It could
> > be made faster, but right now we're flooded with bug reports like "doesn't
> > work" rather than "is too slow". so fixing the rendering bugs is imho
> > currently more important ;)
> I understand. I only hope that there is some room for optimization.

well, visual feedback can be improved without serious problems: 

- we can delay layouting of long pages if parts of it are not visible
- we can change the repaint-frequence to a higher value at the beginning of
parsing a document and put it back to a lower value as soon as the current
visible rectangle is no longer affected by the newly parsed parts. 

another big improvement will happen when/if we are able to improve the CSS
style selector. currently we have a linked list of style rules that can get
very large (>300 elements is not too uncommon). And this linked list is
currently run through for each and every new html element that is added to
the tree. profiling shows that this uses more than 70% of the time during
parsing. Mozilla has fixed this lately, their performance is astonishing
now. So I see not too big problems to change that as well for khtml. It just
needs careful evaluation because breaking the style rules selector will
look very bad for a user ;)


Dirk

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