[webkit-changes] [WebKit/WebKit] 549366: Simplify (and optimize) SVGTextQuery::characterNum...

Chris Dumez noreply at github.com
Thu Sep 28 21:09:41 PDT 2023


  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 549366b2482f6e03e939d2c75669465539514ac6
      https://github.com/WebKit/WebKit/commit/549366b2482f6e03e939d2c75669465539514ac6
  Author: Chris Dumez <cdumez at apple.com>
  Date:   2023-09-28 (Thu, 28 Sep 2023)

  Changed paths:
    M Source/WebCore/rendering/svg/SVGTextQuery.cpp

  Log Message:
  -----------
  Simplify (and optimize) SVGTextQuery::characterNumberAtPositionCallback
https://bugs.webkit.org/show_bug.cgi?id=262347

Reviewed by Ryosuke Niwa.

This method needs to iterate the glyphs within a fragment and check if the
queried point is contained within any of them.
Currently a fragment offset is converted to a offset that's suitable for
passing to mapStartEndPositionsIntoFragmentCoordinates - which then in
turn maps it into a text box-relative offset and then runs (the costly)
modifyStartEndPositionsRespectingLigatures to check if the current range
happen to fall within a "multicharacter glyph" (ligatures etc.), and then
expand the range appropriately.
This is a lot of work, that is better performed by finding the index within
the text metrics list for the corresponding RenderSVGInlineText object,
and then step through the fragment using the lengths of the individual
glyphs.
The impact on performance will vary with the length of fragments and the
length of the text content.
For a case like:

  <text ...>(AAAAAAAAAA ){99}AAAAAAAAAA</text>

  (100 groups of ten A's separated by a single whitespace)

with a negative query, the speed-up is ~1.2x. With 'word-spacing' added
(to get more fragments) the speed-up becomes ~8.7x.

This is a cherry-pick of the following Blink commit:
- https://codereview.chromium.org/353003002

* Source/WebCore/rendering/svg/SVGTextQuery.cpp:
(WebCore::SVGTextQuery::characterNumberAtPositionCallback const):

Canonical link: https://commits.webkit.org/268628@main




More information about the webkit-changes mailing list