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 <[email protected]>: > 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 <[email protected]> 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 >> <[email protected]> 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 >>> [email protected] >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
