Bug 220858 - Move FontCascadeCache onto FontCache
Summary: Move FontCascadeCache onto FontCache
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Lord
URL:
Keywords: InRadar
Depends on:
Blocks: 202793 219283
  Show dependency treegraph
 
Reported: 2021-01-22 03:40 PST by Chris Lord
Modified: 2021-02-22 10:57 PST (History)
9 users (show)

See Also:


Attachments
Patch (16.68 KB, patch)
2021-01-22 04:29 PST, Chris Lord
no flags Details | Formatted Diff | Diff
Patch (16.65 KB, patch)
2021-02-22 01:22 PST, Chris Lord
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Lord 2021-01-22 03:40:41 PST
Currently, FontCascadeCache is a singleton and is managed by some static global functions. This isn't particularly clear as it doesn't follow the convention of being a class with a singleton() method (it's just a typedef of a HashMap). I think it makes sense to integrate it with FontCache - this works well for making FontCache thread-safe, as the FontCascadeCache is also a requirement of using fonts and both can be managed easily using the same lock.
Comment 1 Chris Lord 2021-01-22 04:29:06 PST
Created attachment 418136 [details]
Patch
Comment 2 Radar WebKit Bug Importer 2021-01-29 03:41:14 PST
<rdar://problem/73748595>
Comment 3 Myles C. Maxfield 2021-02-04 12:55:56 PST
Comment on attachment 418136 [details]
Patch

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

> Source/WebCore/ChangeLog:9
> +        Make FontCascadeCache and associated functions a child of FontCache,
> +        accessible via FontCache::singleton.

Why?
Comment 4 Chris Lord 2021-02-05 01:01:05 PST
(In reply to Myles C. Maxfield from comment #3)
> Comment on attachment 418136 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=418136&action=review
> 
> > Source/WebCore/ChangeLog:9
> > +        Make FontCascadeCache and associated functions a child of FontCache,
> > +        accessible via FontCache::singleton.
> 
> Why?

In the world of a thread-safe FontCache, having FontCascadeCache live on it makes it much easier to handle locking with a shared lock. I guess it could just as well be its own class if we promoted it to a full singleton class instead of a HashMap typedef.
Comment 5 Chris Lord 2021-02-22 01:22:49 PST
Created attachment 421170 [details]
Patch
Comment 6 EWS 2021-02-22 03:39:15 PST
Committed r273237: <https://commits.webkit.org/r273237>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 421170 [details].
Comment 7 Darin Adler 2021-02-22 10:57:58 PST
Comment on attachment 421170 [details]
Patch

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

> Source/WebCore/platform/graphics/FontCache.h:188
> +struct FontCascadeCacheEntry {
> +    WTF_MAKE_FAST_ALLOCATED;
> +public:

Just moved code, but: Better style is WTF_MAKE_STRUCT_FAST_ALLOCATED instead.

> Source/WebCore/platform/graphics/FontCache.h:192
> +    FontCascadeCacheEntry(FontCascadeCacheKey&& key, Ref<FontCascadeFonts>&& fonts)
> +        : key(WTFMove(key))
> +        , fonts(WTFMove(fonts))
> +    { }

Just moved code, but: We should be able to remove this and make minimal changes to get everything compiling.

> Source/WebCore/platform/graphics/FontCache.h:198
> +typedef HashMap<unsigned, std::unique_ptr<FontCascadeCacheEntry>, AlreadyHashed> FontCascadeCache;

Just moved code, but: In new code we want "using" here, not "typedef".