Hi,<div><br></div><div>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.</div>

<div><div><br></div><div>Sergiy Byelozyorov</div><div>Computer Graphics Chair</div><div>Universitat des Saarlandes</div><div>Tel.: +49 (681) 302-3837</div><div>Web: <a href="http://graphics.cs.uni-saarland.de/sbyelozyorov/" target="_blank">http://graphics.cs.uni-saarland.de/sbyelozyorov/</a></div>

<div></div><br>
<br><br><div class="gmail_quote">On Fri, Mar 30, 2012 at 19:41, Yong Li <span dir="ltr"><<a href="mailto:yong.li.webkit@gmail.com">yong.li.webkit@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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