[webkit-dev] Why does PositionIterator iterates until the end of the document when selecting?
yong.li.webkit at gmail.com
Fri Mar 30 10:41:43 PDT 2012
I tried skipping hidden nodes bug didn't finish the task
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
>> 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:
>>> 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
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev