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

[Yong Li]

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
>