[Webkit-unassigned] [Bug 177601] Simple and complex paths are not applied consistently

[bugzilla-daemon at webkit.org]

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

--- Comment #18 from Myles C. Maxfield <mmaxfield at apple.com> ---
Comment on attachment 322076
  --> https://bugs.webkit.org/attachment.cgi?id=322076
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=322076&action=review

How sure are you that there isn't a bug with your fast text codepath? Can you explain why we ever opt into the fast text codepath for a situation where we aren't sure that it would get the same results as the complex path?

> Source/WebCore/ChangeLog:20
> +        Due to bug #100050, when rendering text, the complex path is forced in case kerning or shaping is enabled and
> +        only part of the run is going to be rendered. This happens in the GTK+ port when selecting text (except when
> +        selecting the whole run, of course). The text is initially rendered using the simple path as returned by
> +        FontCascade::codePath() and then the selection is rendered using the complex path, overriding what
> +        FontCascade::codePath() returned in that case. This doesn't happen in mac, because the selection is rendered
> +        differently, so FontCascade::drawText always renders the full run (simple path) when selecting text. Selecting
> +        text is the most noticeable inconsistency, but it's not the only one. Similar exceptions are applied when
> +        calculating the text width, or getting the offset of a given position. The rendered text is the simple one, but
> +        the calculations are performed using the complex path, so depending on the kerning and ligatures we might end up
> +        with wrong results. If the text has been rendered using the simple path, the selections and all other
> +        calculations should be performed with the simple path too. This patch moves the condition to force complex text
> +        to FontCascade::codePath(), and only for ports not enabling advance text rendering mode by default. This ensures
> +        that all callers to FontCascade::codePath() will get a consistent result.

I'm not sure this is the correct approach. The source of truth is the complex text codepath; if the fast one gives results which are not the same as the complex path's results, then the fast path is wrong. It sounds like there's just a bug in your simple text codepath.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171027/2d6c4a07/attachment.html>