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

[Sergiy Byelozyorov]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120330/7c6a2174/attachment.html>