Provide fallbacks for web fonts.

Provide fallbacks for web fonts.

This fixes http://code.google.com/p/chromium/issues/detail?id=114531
Committed: https://code.google.com/p/skia/source/detail?r=3231

[reed1, 2012-02-22 21:45:32]

https://codereview.appspot.com/5683078/diff/2001/src/ports/SkFontHost_mac_cor...
File src/ports/SkFontHost_mac_coretext.cpp (right):

https://codereview.appspot.com/5683078/diff/2001/src/ports/SkFontHost_mac_cor...
src/ports/SkFontHost_mac_coretext.cpp:1521: CGGlyph glyph;
Possible speed-up would be to fill a vector of N unichar elements, and call this
guy N at a time (e.g. N == 64, something where we can put the storage for the
unichars and glyphs on the stack...

https://codereview.appspot.com/5683078/diff/2001/src/ports/SkFontHost_mac_cor...
src/ports/SkFontHost_mac_coretext.cpp:1986: if (cfData == NULL) {
Can we just set cfData to the result of CGFontCopyTabeForTab(), and then fall
through to common code that performs the lock/memcpy/etc.?

[caryclark1, 2012-02-22 22:13:06]

https://codereview.appspot.com/5683078/diff/2001/src/ports/SkFontHost_mac_cor...
File src/ports/SkFontHost_mac_coretext.cpp (right):

https://codereview.appspot.com/5683078/diff/2001/src/ports/SkFontHost_mac_cor...
src/ports/SkFontHost_mac_coretext.cpp:1521: CGGlyph glyph;
Seems risky to get right. I'd prefer to identify this as a bottleneck before
optimizing.

On 2012/02/22 21:45:32, reed1 wrote:
> Possible speed-up would be to fill a vector of N unichar elements, and call
this
> guy N at a time (e.g. N == 64, something where we can put the storage for the
> unichars and glyphs on the stack...

https://codereview.appspot.com/5683078/diff/2001/src/ports/SkFontHost_mac_cor...
src/ports/SkFontHost_mac_coretext.cpp:1986: if (cfData == NULL) {
On 2012/02/22 21:45:32, reed1 wrote:
> Can we just set cfData to the result of CGFontCopyTabeForTab(), and then fall
> through to common code that performs the lock/memcpy/etc.?
The helper for CGFontCopy returns NULL and a different data type. I thought
about trying to use more common code, but since they have different types, and
CGFontRelease needs to be called only in the cgFont case, it seemed too
disruptive to rewrite that way, especially if in the long run the CGFont case
can replace the CTFont case altogether.

[reed1, 2012-02-22 22:53:52]

Maybe we're not talking about the same thing. Here is a sample CL that captures
my idea (though it may not be correct)

https://codereview.appspot.com/5687086

https://codereview.appspot.com/5683078/diff/2001/src/ports/SkFontHost_mac_cor...
File src/ports/SkFontHost_mac_coretext.cpp (right):

https://codereview.appspot.com/5683078/diff/2001/src/ports/SkFontHost_mac_cor...
src/ports/SkFontHost_mac_coretext.cpp:1521: CGGlyph glyph;
I'll buy that.

On 2012/02/22 22:13:07, caryclark1 wrote:
> Seems risky to get right. I'd prefer to identify this as a bottleneck before
> optimizing.
> 
> On 2012/02/22 21:45:32, reed1 wrote:
> > Possible speed-up would be to fill a vector of N unichar elements, and call
> this
> > guy N at a time (e.g. N == 64, something where we can put the storage for
the
> > unichars and glyphs on the stack...
>