[Webkit-unassigned] [Bug 65277] Provide flexible (in terms of position relative to space) logical word breaker to improve performance of --webkit-visual-word

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=65277





--- Comment #11 from Xiaomei Ji <xji at chromium.org>  2011-08-09 10:52:21 PST ---
(In reply to comment #8)
> I still don't understand the benefit of this change.  Is there a mesurable difference after this change?  Otherwise, it seems to bloats the code pretty badly.

This patch provides 4 word search functions depends on the word break positions relative to word (before word or after word). The pro is cleaner code logic, and the con is code duplication (we could make existing function previousWordPositionBoundary call previousWordPositionBoundaryLogicallyAfterWord to reduce the duplication, if we want to fix the logical word break behavior across platform).

An alternative is:
add one more parameter in nextBoundary(), previousBoundary(), previousWordPositionBounary(), nextWordPositionBoundary(), findNextWordFromIndex(), and other 6 search functions in visible_unit.cpp (including startSentenceBoundary and endSentenceBounary, in which the newly added parameter is just a placeholder).

Inside function findNextWordFromIndex(), depends on the passing in parameter, return logical word break before or after word.

the word breaker search functions just pass in the IN parameter to findNextWordFromIndex().

the caller of nextBoundary()/previousBoundary() pass in the correct (before word or after word) parameter based on their usage: for visual word break, the value of the parameter depends on the platform, box directionality, and block directionality. For logical word break (previousWordPosition and nextWordPosition), the value of the parameter depends on the platform (editing behavior. related to https://bugs.webkit.org/show_bug.cgi?id=64392).


The pro of the alternative: reduce code duplication, and it could be used to solve issue 64392 as well.
The con of the alternative: adding placeholder parameters to the already heavily parameter-loaded search functions such as startSentenceBoundary().

We are debating on the approaches. Van prefer the approach in the patch, and I prefer the alternative. But we believe neither is ideal. 

Would appreciate your inputs!

One more note, the uploaded patch provides findNextWordFromIndexConsideringWordBreakPositioningRelativeToWord() as a cross-platform function, the existing findNextWordFromIndex() is platform-dependent.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.