RESOLVED FIXED 208266
Optimize Path::encode on platforms that support CGPathGetNumberOfElements 
https://bugs.webkit.org/show_bug.cgi?id=208266
Summary Optimize Path::encode on platforms that support CGPathGetNumberOfElements
Wenson Hsieh
Reported 2020-02-26 14:40:07 PST
We can elide one of the calls to Path::apply() by directly asking for the number of path elements instead.
Attachments
Patch (6.23 KB, patch)
2020-02-29 13:59 PST, Wenson Hsieh 		no flags
DetailsFormatted DiffDiff
Address comments (6.22 KB, patch)
2020-03-01 21:50 PST, Wenson Hsieh 		no flags
DetailsFormatted DiffDiff
Address smfr's comment (6.25 KB, patch)
2020-03-02 13:44 PST, Wenson Hsieh 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2020-02-26 19:01:40 PST
<rdar://problem/59832350>
Wenson Hsieh
Comment 2 2020-02-29 13:59:24 PST
Created attachment 392072 [details] Patch
Darin Adler
Comment 3 2020-03-01 18:35:41 PST
Comment on attachment 392072 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=392072&action=review Do you know the reason for the mysterious Windows failure? It does seem to be new to the patch. > Source/WebCore/platform/graphics/Path.h:136 > + WEBCORE_EXPORT unsigned elementCount() const; 32-bit here > Source/WebCore/platform/graphics/Path.h:234 > + encoder << static_cast<uint64_t>(elementCount()); 64-bit here Why?
Wenson Hsieh
Comment 4 2020-03-01 18:50:57 PST
Comment on attachment 392072 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=392072&action=review >> Source/WebCore/platform/graphics/Path.h:234 >> + encoder << static_cast<uint64_t>(elementCount()); > > 64-bit here > > Why? Good catch! No compelling reason for this difference. elementCount() should return a uint64_t, and then we could just remove the static_cast here.
Wenson Hsieh
Comment 5 2020-03-01 21:49:54 PST
> Do you know the reason for the mysterious Windows failure? It does seem to > be new to the patch. After using the new Retry button, it looks like this was just an unrelated flaky failure (the Win bot is green). The patch should not have changed any behavior on non-Cocoa ports.
Wenson Hsieh
Comment 6 2020-03-01 21:50:50 PST
Created attachment 392116 [details] Address comments
Simon Fraser (smfr)
Comment 7 2020-03-02 13:18:17 PST
Comment on attachment 392116 [details] Address comments View in context: https://bugs.webkit.org/attachment.cgi?id=392116&action=review > Source/WebCore/platform/graphics/Path.h:136 > + WEBCORE_EXPORT uint64_t elementCount() const; Why not size_t
Wenson Hsieh
Comment 8 2020-03-02 13:31:33 PST
Comment on attachment 392116 [details] Address comments View in context: https://bugs.webkit.org/attachment.cgi?id=392116&action=review >> Source/WebCore/platform/graphics/Path.h:136 >> + WEBCORE_EXPORT uint64_t elementCount() const; > > Why not size_t Sure, I suppose that would be clearer.
Wenson Hsieh
Comment 9 2020-03-02 13:44:02 PST
Created attachment 392183 [details] Address smfr's comment
WebKit Commit Bot
Comment 10 2020-03-05 08:13:24 PST
The commit-queue encountered the following flaky tests while processing attachment 392183 [details]: editing/spelling/spellcheck-async-remove-frame.html bug 158401 (authors: morrita@google.com, rniwa@webkit.org, and tony@chromium.org) The commit-queue is continuing to process your patch.
WebKit Commit Bot
Comment 11 2020-03-05 08:14:02 PST
Comment on attachment 392183 [details] Address smfr's comment Clearing flags on attachment: 392183 Committed r257918: <https://trac.webkit.org/changeset/257918>
WebKit Commit Bot
Comment 12 2020-03-05 08:14:03 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.