Bug 196846 – [Cocoa] FontPlatformData objects aren't cached at all when using font-family:system-ui

• Component: New Bugs
• Status: NEW

[Myles C. Maxfield]

[Cocoa] FontPlatformData objects aren't cached at all when using font-family:system-ui

[Myles C. Maxfield]

Created attachment 367278 [details]
WIP

[Myles C. Maxfield]

<rdar://problem/49499971>

[EWS Watchlist]

Attachment 367278 [details] did not pass style-queue:


ERROR: Source/WebCore/ChangeLog:9:  You should remove the 'No new tests' and either add and list tests, or explain why no new tests were possible.  [changelog/nonewtests] [5]
Total errors found: 1 in 5 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[EWS Watchlist]

Comment on attachment 367278 [details]
WIP

Attachment 367278 [details] did not pass mac-debug-ews (mac):
Output: https://webkit-queues.webkit.org/results/11849345

New failing tests:
webgl/2.0.0/conformance/context/context-release-upon-reload.html

[EWS Watchlist]

Created attachment 367285 [details]
Archive of layout-test-results from ews115 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[Myles C. Maxfield]

Test failure is unrelated

[Myles C. Maxfield]

Created attachment 367372 [details]
WIP

[Myles C. Maxfield]

16.8x increase in performance on the benchmark!!

[Myles C. Maxfield]

Created attachment 367402 [details]
Patch

[Darin Adler]

Comment on attachment 367402 [details]
Patch

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

> Source/WebCore/platform/graphics/cocoa/FontFamilySpecificationCoreText.cpp:53
> +    static inline bool safeCFEqual(CFTypeRef a, CFTypeRef b)
> +    {
> +        return (!a && !b) || (a && b && CFEqual(a, b));
> +    }

Seems like this could be a helper somewhere else to be shared with other call sites instead of here in the class. I would search for other calls to CFEqual in WebKit to see what we can share with.

> Source/WebCore/platform/graphics/cocoa/FontFamilySpecificationCoreText.cpp:69
> +        return (fontDescriptor ? CFHash(fontDescriptor.get()) : 0) ^ fontDescriptionKey.computeHash();

To combine two hashes to make a single result like this, which is a suboptimal idiom, but sometimes necessary, I suggest using pairIntHash from HashFunctions.h rather than exclusive or.

Also seems like we could put "safeCFHash" in the same place as "safeCFEqual" and make this nicer.

[Darin Adler]

Comment on attachment 367402 [details]
Patch

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

> Source/WebCore/platform/graphics/cocoa/FontFamilySpecificationCoreText.cpp:38
> +struct FontFamilySpecificationKey {

Sure would be nice if this struct could be a. lot simpler. So many lines of code! Need to fix our hashing machinery so this idiom is not so complex.

> Source/WebCore/platform/graphics/cocoa/FontFamilySpecificationCoreText.cpp:48
> +    explicit FontFamilySpecificationKey(WTF::HashTableDeletedValueType hashTableDeletedValueType)
> +        : fontDescriptionKey(hashTableDeletedValueType)
> +    { }

Argument name here is peculiar. Should not include the word "type" in the name of an argument. I think I would call it "deletedValue".

> Source/WebCore/platform/graphics/cocoa/FontFamilySpecificationCoreText.cpp:87
> +    static unsigned hash(const FontFamilySpecificationKey& key)
> +    {
> +        return key.computeHash();
> +    }
> +
> +    static bool equal(const FontFamilySpecificationKey& a, const FontFamilySpecificationKey& b)
> +    {
> +        return a == b;
> +    }
> +
> +    static const bool safeToCompareToEmptyOrDeleted = true;

Style-wise seems it would be nicer to use one-liners like in HashFunctions.h for these functions.

[Myles C. Maxfield]

Created attachment 367465 [details]
Patch for committing

[WebKit Commit Bot]

Comment on attachment 367465 [details]
Patch for committing

Clearing flags on attachment: 367465

Committed r244315: <https://trac.webkit.org/changeset/244315>

[Darin Adler]

Comment on attachment 367465 [details]
Patch for committing

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

> Source/WTF/wtf/RetainPtr.h:374
> +    return (!a && !b) || (a && b && CFEqual(a, b));

I have an idea for an alternate implementation and I wonder which is more efficient in the most important cases. Here’s my alternative:

    return (a == b) || (a && b && CFEqual(a, b));

[Simon Fraser (smfr)]

(In reply to Darin Adler from comment #14)
> Comment on attachment 367465 [details]
> Patch for committing
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=367465&action=review
> 
> > Source/WTF/wtf/RetainPtr.h:374
> > +    return (!a && !b) || (a && b && CFEqual(a, b));
> 
> I have an idea for an alternate implementation and I wonder which is more
> efficient in the most important cases. Here’s my alternative:
> 
>     return (a == b) || (a && b && CFEqual(a, b));

This looks like a CF equivalent of WTF::arePointingToEqualData()

[Myles C. Maxfield]

Comment on attachment 367465 [details]
Patch for committing

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

>>> Source/WTF/wtf/RetainPtr.h:374
>>> +    return (!a && !b) || (a && b && CFEqual(a, b));
>> 
>> I have an idea for an alternate implementation and I wonder which is more efficient in the most important cases. Here’s my alternative:
>> 
>>     return (a == b) || (a && b && CFEqual(a, b));
> 
> This looks like a CF equivalent of WTF::arePointingToEqualData()

How confident are we that CFEqual doesn't do the shallow comparison already? If so, then this idea would be faster if the CFEqual call hasn't already been loaded or isn't in the instruction cache. CFEqual is a pretty common operation, so I'm not sure whether or not it would be better.

[Simon Fraser (smfr)]

https://github.com/opensource-apple/CF/blob/master/CFRuntime.c#L694

[Darin Adler]

Comment on attachment 367465 [details]
Patch for committing

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

>>>> Source/WTF/wtf/RetainPtr.h:374
>>>> +    return (!a && !b) || (a && b && CFEqual(a, b));
>>> 
>>> I have an idea for an alternate implementation and I wonder which is more efficient in the most important cases. Here’s my alternative:
>>> 
>>>     return (a == b) || (a && b && CFEqual(a, b));
>> 
>> This looks like a CF equivalent of WTF::arePointingToEqualData()
> 
> How confident are we that CFEqual doesn't do the shallow comparison already? If so, then this idea would be faster if the CFEqual call hasn't already been loaded or isn't in the instruction cache. CFEqual is a pretty common operation, so I'm not sure whether or not it would be better.

Yes, CFEqual does do the shallow comparison; I didn’t mean to imply that it didn’t. But I don’t understand your logic about which version is slightly better. I’m pretty sure that my alternative generates smaller code with one fewer branch, for example.