Currently, font generic families are stored on the Settings base class, which means they don't get transferred over to Workers via Settings::Values - this is necessary for OffscreenCanvas, and perhaps there are other reasons this would be desirable (it would seem logical to keep all Settings storage in Settings::Values rather than just almost-all).
Created attachment 418051 [details] Patch
Created attachment 418052 [details] Patch
Created attachment 418055 [details] Patch
Comment on attachment 418055 [details] Patch r=mews
Created attachment 418120 [details] Patch
Committed r271742: <https://trac.webkit.org/changeset/271742> All reviewed patches have been landed. Closing bug and clearing flags on attachment 418120 [details].
<rdar://problem/73492040>
Here are the parts of this we want to be careful about: 1) Performance cost, slowing down by calling AtomString repeatedly. If the cost is at all an issue, it can be minimized by "atomizing" when setting family names even though the storage is not done as AtomString. It’s quick to detect the AtomString bit. That can be done by converting to AtomString and back to a String. 2) Memory cost, is there some path that ends up accumulating multiple copies of the same family name. There are multiple ways to make sure this doesn’t occur. When using AtomString this is automatically taken care of, we also share a single string. Without AtomString we need to double check that we don’t unnecessarily end up with multiple copies of the same string in memory. Could explicitly optimize with things like checks for strings that happen to be equal. When we do an isolated copy we always guarantee we have fresh strings, so we might have to actively do something so we don’t end up with many multiple copies. I doubt either of those two are a big problem, but both are worth thinking through or measuring.
Looks like this broke the internal WatchOS build
Not sure this change has anything to do with the breakage I saw.