Followup from #1500
Repro steps:
@jboo1212@jboo1212I've tracked things down to this line in TextStyle.swift from the StyledText lib.
Before backgrounding, when bolding works, the UIFont returned has the following descriptor:
UICTFontDescriptor <0x1c42a3e40> = {
NSCTFontUIUsageAttribute = CTFontRegularUsage;
NSFontSizeAttribute = 16;
}
After backgrounding and re-rendering, the descriptor is
UICTFontDescriptor <0x1c80b7400> = {
NSFontNameAttribute = ".SFUIText";
NSFontSizeAttribute = 16;
}
Note the .SFUIText which means the font is loaded via family name and not the system style, so when we union a bold font trait, it fails and just returns the same font (we want the SF semibold font for bold).
Trying to understand what exactly could be happening, but wanted to document what I've found and see if anyone else has seen something like this.
Note that fonts are loaded on a background queue b/c that's how things are designed atm. Haven't experimented loading on main, which we can't do yet b/c of performance and architecture reasons. Finding a way to do that might be the fix? Not sure.
Oh wow this is interesting, thanks for documenting. Curious to see what caused this. If it is the background queue, hooray to the Main Thread checker for the hint?
Doesn鈥檛 explain why it works fine the first time tho... this one is really really weird. Lets see if it reproduces on the simulator.
edit: it does
Sent with GitHawk
Has to be something I'm doing wrong. Breaking in the comment parsing, which is done on a background queue, shows this:
(lldb) po UIFont(descriptor: UIFont.systemFont(ofSize: 1).fontDescriptor, size: 16).fontDescriptor
UICTFontDescriptor <0x6000000be360> = {
NSCTFontUIUsageAttribute = CTFontRegularUsage;
NSFontSizeAttribute = 16;
}
(lldb) po Styles.Text.body.preferredFont.fontDescriptor
UICTFontDescriptor <0x6040002a8dc0> = {
NSFontNameAttribute = ".SFUIText";
NSFontSizeAttribute = 16;
}
The way I'm recreating the UIFont on that first execution is basically exactly how its done inside our helpers and the StyledText lib...
Even though this is fixed, I never was able to pinpoint what exactly was wrong. I tried reproducing this in a sample app and nothing broke (even when doing backgrounding stuff). After evaluating the TextStyle architecture, I figured it was wrong anyways and decided on using a smarter combination of system fonts instead of hacking at UIFontDescriptor to get system font styles.
Most helpful comment
Even though this is fixed, I never was able to pinpoint what exactly was wrong. I tried reproducing this in a sample app and nothing broke (even when doing backgrounding stuff). After evaluating the
TextStylearchitecture, I figured it was wrong anyways and decided on using a smarter combination of system fonts instead of hacking atUIFontDescriptorto get system font styles.