[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 #19 from Xiaomei Ji <xji at chromium.org>  2011-08-11 22:20:48 PST ---
(In reply to comment #17)
> The measured performance improvements don't seem particularly large. Also, our problem is with calling these functions many times for each operation, not necessarily with them being slow.

Yes. you are right. The problem is calling these functions many times.
And the improvement is to decrease the number of calls.

When we compute visual word breaks, we are calling logical word break many times because logical word break does not return the correct (in terms of before or after space) word break position visual word breaker is looking for.

For example,
given a string "abc def hij",  nextWordPosition() returns the following position "abc| def| hij", and previousWordPosition() returns the following position "|abc |def |hij".
when start from beginning and move left to right, if the visual word break I am looking for is "abc |def |hij", 
then, I am not able to use nextWordPosition(). Instead,  I collected the word breaks inside this box starting from end of the string and using previousWordPosition(), the collected word breaks are "abc def |hij", then, "abc |def hij", then, "|abc def hij".  And by comparing the word break offset and current position offset, return "abc |def hij" as the visual word break.

The proposed improvement is to provide an *internal* API which can return flexible logical word break in terms of space. Given the above example, if there is an *internal* API that returns "abc |def |hij" as logical next word breaker, then, I can use that to get the visual word breaker in one call.

> 
> I think that prior to adding new code, we should better define the concepts it works with. Different ports return drastically different results for word boundaries, and considering how basic these operations are, that causes really ugly bugs (see e.g. bug 65898 or bug 65999). 
> While we cannot even agree upon what word boundaries are, adding "word boundaries considering word break positioning" seems counter-productive.

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