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

List:       kfm-devel
Subject:    Re: patch + examples, change frameset.rows from js
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-12-23 23:14:46
[Download RAW message or body]

On Sunday 23 December 2001 17:10, koos.vriezen@xs4all.nl wrote:
> > My examples work, but (like mentioned in 'Very slow konqy / khtml on
> > www.freshmeat.net' posting, it seems to have trouble removing nodes from
> > changeNodes.
> > You didn't use m_docChanged but m_changed. Wouldn't this trigger a
> > applyChanges on a whole document?
> 
> The attached patch re-introduce m_docChanged. This seems to fix the
> www.freshmeat.net bug.

I think you're right, we can't reuse the same bool after all, it's a different
meaning. Dirk suggested (on IRC) that I used the same bool, but indeed
it looks wrong... or I misunderstood Dirk, maybe.

> > Does a call to setChanged on a DocumentImpl node, add this node twice to
> > changedNodes? (Maybe QList is smart enough for not adding thing twice)
No, a QList can have duplicates, so indeed we have to do that check ourselves

> > void NodeImpl::setChanged(bool b)
> > {
> >     if (b && !attached()) // changed compared to what?
> >         return;
> >     if (b && !changed() && ownerDocument())
The !changed() here is what tells me that we're not appending twice...
But I'm not 100% sure of that reasoning, need to look at this stuff closer once again :}

Thanks for the patch, I have applied it.
Will do some testing if I find the time.

BTW, you need to know that Dirk considers this whole "changed nodes / changed documents"
a temporary solution, and that he wants to go for a better solution in the long run, for
more optimizations.
"changed: true/false" is pretty basic, we could e.g. have more precise flags to know
what has changed. Another idea is to store that "changed" flag in the render tree
rather than in the dom tree, in order to allow some optimizations (e.g. for tables etc.).
This needs to be discussed first, obviously (and I don't know enough about it
to actually start a discussion) - I just wanted to warn you about the fact that
this code might be thrown away later. I'm quite happy with the "make it work first,
optimize later" idea though, those problems have been outstanding for too long.
Thanks for your contributions!

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://www.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today


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