[webkit-dev] Why does PositionIterator iterates until the end of the document when selecting?

Sergiy Byelozyorov byelozyorov at cs.uni-saarland.de
Fri Mar 30 16:27:58 PDT 2012


Hi,

Thanks for the link. I think it would be sufficient help in my case already
to skip content of nodes without a renderer (I have few thousands of them,
but it's far less than number of characters). I was also using outdated
version of WebKit - revisition 101748. I will try to either integrate your
patch in the version that I have or update to the newest version.

Sergiy Byelozyorov
Computer Graphics Chair
Universitat des Saarlandes
Tel.: +49 (681) 302-3837
Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/



On Fri, Mar 30, 2012 at 19:41, Yong Li <yong.li.webkit at gmail.com> wrote:

> I tried skipping hidden nodes bug didn't finish the task
> (https://bugs.webkit.org/show_bug.cgi?id=65377).
>
> It would be very nice we can skip entire nodes when possible.
>
>
> 2012/3/30 Sergiy Byelozyorov <byelozyorov at cs.uni-saarland.de>:
> > I see now. However, this creates a problem if the nearest position is
> really
> > far. In my case we are having a huge document with over ~300 million
> > characters all of which are not selectable. Just iterating over all of
> these
> > characters takes over 10 seconds.
> >
> > I think the solution would be to add a possibility to skip the element
> with
> > its children alltogether into increment function by calling
> > new Node::areChildrenSelectable method. This would return true by default
> > and will be overriden in some element types. Do you think it's a feasible
> > solution? I am worried about the cost to the virtual function call,
> however
> > it should only cause problems if there are really many elements as well.
> Is
> > PositionInterator used somewhere else other than in selecting charaters?
> >
> > P.S. All of this text is actually not even displayed - it is used as 3D
> > vertex arrays for geometry.
> >
> >
> > Sergiy Byelozyorov
> > Computer Graphics Chair
> > Universitat des Saarlandes
> > Tel.: +49 (681) 302-3837
> > Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/
> >
> >
> >
> > On Thu, Mar 29, 2012 at 22:56, Ojan Vafai <ojan at chromium.org> wrote:
> >>
> >> One case where this matters: <div
> >> style="-webkit-user-select:none">foo</div>bar
> >>
> >> If you mousedown on foo and drag right, you want to start selecting
> >> bar. In the common case, we don't do any walking. The next position we
> grab
> >> from the iterator is valid and we use it.
> >>
> >> On Thu, Mar 29, 2012 at 7:27 AM, Sergiy Byelozyorov
> >> <byelozyorov at cs.uni-saarland.de> wrote:
> >>>
> >>> Hi,
> >>>
> >>> When searching for the character to be selected (on mouse click), we
> run
> >>> an interator over the characters to determine the one under the
> cursor. I am
> >>> trying to understand why does PositionInterator that is used in this
> case
> >>> iterates over all characters starting from the element that was
> clicked and
> >>> until the end of the document(!). The following method is called to
> verify
> >>> whether PositionIterator has finished traversing the characters (see
> >>> comments inline):
> >>>
> >>> bool PositionIterator::atEnd() const
> >>>
> >>> {
> >>>
> >>>     if (!m_anchorNode) // This is clear - if we don't have an an
> anchor -
> >>> then we are done.
> >>>
> >>>         return true;
> >>>
> >>>     if (m_nodeAfterPositionInAnchor) // This is also understandable -
> if
> >>> there is a next position then we are not at the end.
> >>>
> >>>         return false;
> >>>
> >>>     // This is what puzzles me. First check will be true until we will
> >>> reach the root of the Document.
> >>>
> >>>     return !m_anchorNode->parentNode() &&
> (m_anchorNode->hasChildNodes()
> >>> || m_offsetInAnchor >= lastOffsetForEditing(m_anchorNode));
> >>>
> >>> }
> >>>
> >>>
> >>> Is this the intended behaviour? Why wouldn't we just stay within the
> >>> element that was clicked on? This would save us a lot of CPU cycles
> because
> >>> we won't be checking text that in all other elements until the end of
> the
> >>> document, wouldn't it? This check has been around since at least 2004,
> so I
> >>> doub't that it's wrong, but I don't get the logic here. Please explain
> this
> >>> to me. Thanks.
> >>>
> >>> Sergiy Byelozyorov
> >>> Computer Graphics Chair
> >>> Universitat des Saarlandes
> >>> Tel.: +49 (681) 302-3837
> >>> Web: http://graphics.cs.uni-saarland.de/sbyelozyorov/
> >>>
> >>>
> >>> _______________________________________________
> >>> webkit-dev mailing list
> >>> webkit-dev at lists.webkit.org
> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>>
> >>
> >
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120331/55f23d95/attachment.html>


More information about the webkit-dev mailing list