Text Selection Speed

[Koos Vriezen]

On Sun, 23 Jun 2002, Dirk Mueller wrote:
> On Sam, 22 Jun 2002, Koos Vriezen wrote:
>
> > Attached a patch that contains my two previous patches, only repaint the
> > selected object and the re-scheduling changes, with some improvements.
>
> - what you hacked together with QValueList<QRect> is handled MUCH more
>   efficiently in QRegion. Please use that instead.

Didn't know that. Why isn't it used then?

> - DocumentImpl is not part of the public interface. there is no need
>   to add a Private class to it.

Yes, just don't wanted to include render_object.h in dom_docimpl.h. But
it's not important.

>
> > It also adds 'cachedInnerNode' to DocumentImpl.
>
> which is broken.
>
> > 'DocumentImpl::prepareMouseEvent' first looks if the mouse is still in
> > this object, before rescanning the rendering tree. This saves a lot of CPU
> > cycles when moving the mouse above khtml part.
>
> And doesn't work. while the mouse might be still inside the previous
> "innernode", there might be a new "more inner" innernode now. Your caching
> breaks for this case.

Already had
  if (d->cachedInnerNode &&
      d->cachedInnerNode->innerNode()->renderer()->nodeAtPoint(......)) {
         if (d->cachedInnerNode->URLElement() && !renderInfo.URLElement())
            renderInfo.setURLElement(d->cachedInnerNode->URLElement());
         *d->cachedInnerNode = renderInfo;
         isInside = true;
  } else
in my tree, which always updates the cache. Also an invalidation
of the cache in 'DocumentImpl::close' was necessary.
But yes, caching is dangerous but also fast.

>
> Believe me, if it had been that simple it would be already implemented ;-)

Nonsense ;)

> > There is no reference counting in Render*, so I'm not 100% sure this
> > cached node is always valid.
>
> Yes, additional headache.
>
>
> Dirk
>