Access font tables in memory

Zero-copy font table access for HarfBuzz

Our previous implementation relied on the copy function
harfBuzzSkiaGetTable() to create a font table copy, which is held by
hb_face_t and hb_font_t in turn. This allocation is additional overhead
in terms of memory consumption and allocation cost.

Using Skia's openStream() API we can retrieve the SkStreamAsset for the
SkTypeface. On desktop Linux, on Android and on Windows my
experimentation shows that this SkStreamAsset is available from memory
most of the time and calling getMemoryBase() returns a valid
address. The openStream() call itself duplicates and SkStream
internally, but does not duplicate the underlying in-memory data.

From The SkStreamAsset we can wrap the font data into an hb_blob_t for
consumption by hb_face_create. openStream() transfers ownerships of the
returned SkStreaAsset to the caller, so we have to specifiy a
destruction function to HarfBuzz when hb_face_t releases the hb_blob_t.

This CL saves all time and space for additional table allocations
required for text shaping, which can range from a few kilobytes for a
set of Latin fonts to hundreds of kilobytes for multiple fonts with
large tables accessed by HarfBuzz.

BUG=621878
Committed: https://crrev.com/264e1435dc66fbc7029d5472f334d185d70aea49
Cr-Commit-Position: refs/heads/master@{#402262}

[drott, 2016-06-20 12:13:01]

The CQ bit was checked by drott@chromium.org to run a CQ dry run

[drott, 2016-06-20 12:13:02]

Mac compile fix

[commit-bot: I haz the power, 2016-06-20 12:13:13]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2080243002/20001

[commit-bot: I haz the power, 2016-06-20 13:35:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-20 13:35:57]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[drott, 2016-06-21 07:46:18]

Fix leaking hb_blob_t

[drott, 2016-06-21 08:43:23]

The CQ bit was checked by drott@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-21 08:43:38]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2080243002/40001

[drott, 2016-06-21 11:15:56]

Description was changed from

==========
Access font tables in memory

BUG=
==========

to

==========
Zero-copy font table access for HarfBuzz

Our previous implementation relied on the copy function
harfBuzzSkiaGetTable() to create a font table copy, which is held by
hb_face_t and hb_font_t in turn. This allocation is additional overhead
in terms of memory consumption and allocation cost.

Using Skia's openStream() API we can retrieve the SkStreamAsset for the
SkTypeface. On desktop Linux, on Android and on Windows my
experimentation shows that this SkStreamAsset is always accessible in
memory, since the getMemoryBase() returns a valid address. The
openStream() call itself duplicates and SkStream internally, but does
not duplicate the underlying in-memory data.

From The SkStreamAsset we can wrap the font data into an hb_blob_t for
consumption by hb_face_create. openStream() transfers ownerships of the
returned SkStreaAsset to the caller, so we have to specifiy a
destruction function to HarfBuzz when hb_face_t releases the hb_blob_t.

This CL saves all time and space for additional table allocations
required for text shaping, which can range from a few kilobytes for a
set of Latin fonts to hundreds of kilobytes for multiple fonts with
large tables accessed by HarfBuzz.

BUG=621878
==========

[drott, 2016-06-21 11:15:56]

drott@chromium.org changed reviewers:
+ behdad@chromium.org, bungeman@chromium.org, eae@chromium.org,
fmalita@chromium.org, tzik@chromium.org

[drott, 2016-06-21 11:16:45]

This is ready for review now, although I need to work out and discuss with
Behdad the two glyph choice failures on Windows. It might only be trybot
flakiness.

[drott, 2016-06-21 11:18:51]

Simplify fallback case

[drott, 2016-06-21 11:19:35]

The CQ bit was checked by drott@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-21 11:19:48]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2080243002/60001

[eae, 2016-06-21 11:20:51]

LGTM

Awesome!

[drott, 2016-06-21 11:26:52]

Description was changed from

==========
Zero-copy font table access for HarfBuzz

Our previous implementation relied on the copy function
harfBuzzSkiaGetTable() to create a font table copy, which is held by
hb_face_t and hb_font_t in turn. This allocation is additional overhead
in terms of memory consumption and allocation cost.

Using Skia's openStream() API we can retrieve the SkStreamAsset for the
SkTypeface. On desktop Linux, on Android and on Windows my
experimentation shows that this SkStreamAsset is always accessible in
memory, since the getMemoryBase() returns a valid address. The
openStream() call itself duplicates and SkStream internally, but does
not duplicate the underlying in-memory data.

From The SkStreamAsset we can wrap the font data into an hb_blob_t for
consumption by hb_face_create. openStream() transfers ownerships of the
returned SkStreaAsset to the caller, so we have to specifiy a
destruction function to HarfBuzz when hb_face_t releases the hb_blob_t.

This CL saves all time and space for additional table allocations
required for text shaping, which can range from a few kilobytes for a
set of Latin fonts to hundreds of kilobytes for multiple fonts with
large tables accessed by HarfBuzz.

BUG=621878
==========

to

==========
Zero-copy font table access for HarfBuzz

Our previous implementation relied on the copy function
harfBuzzSkiaGetTable() to create a font table copy, which is held by
hb_face_t and hb_font_t in turn. This allocation is additional overhead
in terms of memory consumption and allocation cost.

Using Skia's openStream() API we can retrieve the SkStreamAsset for the
SkTypeface. On desktop Linux, on Android and on Windows my
experimentation shows that this SkStreamAsset is available from memory
most of the time and calling getMemoryBase() returns a valid
address. The openStream() call itself duplicates and SkStream
internally, but does not duplicate the underlying in-memory data.

From The SkStreamAsset we can wrap the font data into an hb_blob_t for
consumption by hb_face_create. openStream() transfers ownerships of the
returned SkStreaAsset to the caller, so we have to specifiy a
destruction function to HarfBuzz when hb_face_t releases the hb_blob_t.

This CL saves all time and space for additional table allocations
required for text shaping, which can range from a few kilobytes for a
set of Latin fonts to hundreds of kilobytes for multiple fonts with
large tables accessed by HarfBuzz.

BUG=621878
==========

[drott, 2016-06-21 11:30:44]

Thank you!

I'd like to hear an opinion from the Skia team as well, thanks in advance for
taking a look, fmalita@ or bungeman@.

[commit-bot: I haz the power, 2016-06-21 13:06:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-21 13:06:02]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Ilya Kulshin, 2016-06-21 15:43:41]

kulshin@chromium.org changed reviewers:
+ kulshin@chromium.org

[Ilya Kulshin, 2016-06-21 15:43:42]

https://codereview.chromium.org/2080243002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp (right):

https://codereview.chromium.org/2080243002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp:334:
reinterpret_cast<const char*>(typefaceStream->getMemoryBase()),
I'm not familiar with how harfbuzz handles object lifetime, but I wanted to
point out that the pointer returned from getMemoryBase is only valid as long as
the underlying SkDWriteFontFileStream remains alive. If there's any chance that
memory might be used after the SkStreamAsset is destroyed, it's worth
doublechecking.

https://codereview.chromium.org/2080243002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp:344: face =
hb_face_create_for_tables(harfBuzzSkiaGetTable, m_platformData->typeface(), 0);
Doesn't this always overwrite |face| and ignore the result of the new code?

[drott, 2016-06-22 07:14:08]

Do not oversimplify fallback case

[drott, 2016-06-22 07:15:25]

On 2016/06/21 at 15:43:42, kulshin wrote:
>
https://codereview.chromium.org/2080243002/diff/60001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp
(right):
> 
>
https://codereview.chromium.org/2080243002/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp:334:
reinterpret_cast<const char*>(typefaceStream->getMemoryBase()),
> I'm not familiar with how harfbuzz handles object lifetime, but I wanted to
point out that the pointer returned from getMemoryBase is only valid as long as
the underlying SkDWriteFontFileStream remains alive. If there's any chance that
memory might be used after the SkStreamAsset is destroyed, it's worth
doublechecking.
> 
>
https://codereview.chromium.org/2080243002/diff/60001/third_party/WebKit/Sour...
> third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp:344: face =
hb_face_create_for_tables(harfBuzzSkiaGetTable, m_platformData->typeface(), 0);
> Doesn't this always overwrite |face| and ignore the result of the new code?

[drott, 2016-06-22 07:19:48]

Thanks for the review, Ilya.

https://codereview.chromium.org/2080243002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp (right):

https://codereview.chromium.org/2080243002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp:334:
reinterpret_cast<const char*>(typefaceStream->getMemoryBase()),
On 2016/06/21 at 15:43:42, Ilya Kulshin wrote:
> I'm not familiar with how harfbuzz handles object lifetime, but I wanted to
point out that the pointer returned from getMemoryBase is only valid as long as
the underlying SkDWriteFontFileStream remains alive. If there's any chance that
memory might be used after the SkStreamAsset is destroyed, it's worth
doublechecking.

Thanks for pointing that out. The hb_face_create() call references the
hb_blobt_t and keeps it alive until the hb_face_t itself gets destroyed. Then,
the destruction function deleteTypeFaceStream is called, which destroys the
SkStreamAsset. So the lifetime of the SkStreamAsset is coupled to the hb_face_t.
So, as long as we have a FontPlatformData (with an SkTypeface member) we have a
HarfBuzzFace, which has the hb_font_t, which keeps the hb_face_t. So, it looks
to me like the lifecycle of the SkStreamAsset is sound.

https://codereview.chromium.org/2080243002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp:344: face =
hb_face_create_for_tables(harfBuzzSkiaGetTable, m_platformData->typeface(), 0);
On 2016/06/21 at 15:43:42, Ilya Kulshin wrote:
> Doesn't this always overwrite |face| and ignore the result of the new code?

Oups, yes, my bad. There was an "if (face)" in my first version and I
"simplified" that away.

[drott, 2016-06-22 07:36:57]

The CQ bit was checked by drott@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-22 07:37:05]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2080243002/80001

[commit-bot: I haz the power, 2016-06-22 09:39:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-22 09:39:59]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[Ilya Kulshin, 2016-06-22 14:39:45]

lgtm

[behdad, 2016-06-23 13:27:37]

https://codereview.chromium.org/2080243002/diff/80001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp (right):

https://codereview.chromium.org/2080243002/diff/80001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp:340: face =
hb_face_create(faceBlob.get(), 0);
Instead of 0, you need the TTC index of the face.  Does Skia have that readily?

[drott, 2016-06-27 08:59:28]

On 2016/06/23 at 13:27:37, behdad wrote:
>
https://codereview.chromium.org/2080243002/diff/80001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp
(right):
> 
>
https://codereview.chromium.org/2080243002/diff/80001/third_party/WebKit/Sour...
> third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp:340: face =
hb_face_create(faceBlob.get(), 0);
> Instead of 0, you need the TTC index of the face.  Does Skia have that
readily?

The parameter to open stream is an out parameter. More correctly, i should
specify a nullptr there since we're not interested in it, but:

     *  If ttcIndex is not null, it is set to the TrueTypeCollection index
     *  of this typeface within the stream, or 0 if the stream is not a
     *  collection.

So it might still be somehow related to ttc's but specifying an argument is not
the fix.

Ilya, any other idea why we see failures on Windows? "Cambria Math" (used in the
SVG test) is indeed a .ttc.

[f(malita), 2016-06-27 12:56:09]

Description was changed from

==========
Zero-copy font table access for HarfBuzz

Our previous implementation relied on the copy function
harfBuzzSkiaGetTable() to create a font table copy, which is held by
hb_face_t and hb_font_t in turn. This allocation is additional overhead
in terms of memory consumption and allocation cost.

Using Skia's openStream() API we can retrieve the SkStreamAsset for the
SkTypeface. On desktop Linux, on Android and on Windows my
experimentation shows that this SkStreamAsset is available from memory
most of the time and calling getMemoryBase() returns a valid
address. The openStream() call itself duplicates and SkStream
internally, but does not duplicate the underlying in-memory data.

From The SkStreamAsset we can wrap the font data into an hb_blob_t for
consumption by hb_face_create. openStream() transfers ownerships of the
returned SkStreaAsset to the caller, so we have to specifiy a
destruction function to HarfBuzz when hb_face_t releases the hb_blob_t.

This CL saves all time and space for additional table allocations
required for text shaping, which can range from a few kilobytes for a
set of Latin fonts to hundreds of kilobytes for multiple fonts with
large tables accessed by HarfBuzz.

BUG=621878
==========

to

==========
Zero-copy font table access for HarfBuzz

Our previous implementation relied on the copy function
harfBuzzSkiaGetTable() to create a font table copy, which is held by
hb_face_t and hb_font_t in turn. This allocation is additional overhead
in terms of memory consumption and allocation cost.

Using Skia's openStream() API we can retrieve the SkStreamAsset for the
SkTypeface. On desktop Linux, on Android and on Windows my
experimentation shows that this SkStreamAsset is available from memory
most of the time and calling getMemoryBase() returns a valid
address. The openStream() call itself duplicates and SkStream
internally, but does not duplicate the underlying in-memory data.

From The SkStreamAsset we can wrap the font data into an hb_blob_t for
consumption by hb_face_create. openStream() transfers ownerships of the
returned SkStreaAsset to the caller, so we have to specifiy a
destruction function to HarfBuzz when hb_face_t releases the hb_blob_t.

This CL saves all time and space for additional table allocations
required for text shaping, which can range from a few kilobytes for a
set of Latin fonts to hundreds of kilobytes for multiple fonts with
large tables accessed by HarfBuzz.

BUG=621878
==========

[f(malita), 2016-06-27 12:56:09]

fmalita@chromium.org changed reviewers:
+ reed@google.com

[f(malita), 2016-06-27 13:35:12]

On 2016/06/27 08:59:28, drott wrote:
> On 2016/06/23 at 13:27:37, behdad wrote:
> >
>
https://codereview.chromium.org/2080243002/diff/80001/third_party/WebKit/Sour...
> > File third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp
> (right):
> > 
> >
>
https://codereview.chromium.org/2080243002/diff/80001/third_party/WebKit/Sour...
> > third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp:340: face
=
> hb_face_create(faceBlob.get(), 0);
> > Instead of 0, you need the TTC index of the face.  Does Skia have that
> readily?
> 
> The parameter to open stream is an out parameter. More correctly, i should
> specify a nullptr there since we're not interested in it, but:
> 
>      *  If ttcIndex is not null, it is set to the TrueTypeCollection index
>      *  of this typeface within the stream, or 0 if the stream is not a
>      *  collection.

I'm not very familiar with either API, but SkTypeface::openStream() returns a
TTC index, and hb_face_create() wants one - don't we just need to pass the
former to the latter?  I.e.

  int ttcIndex;
  SkStreamAsset* typefaceStream = typeface->openStream(&ttcIndex);
  ...
      face = hb_face_create(faceBlob.get(), ttcIndex);

[drott, 2016-06-27 17:55:23]

On 2016/06/27 at 13:35:12, fmalita wrote:
> On 2016/06/27 08:59:28, drott wrote:
> > On 2016/06/23 at 13:27:37, behdad wrote:
> > >
> >
https://codereview.chromium.org/2080243002/diff/80001/third_party/WebKit/Sour...
> > > File third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp
> > (right):
> > > 
> > >
> >
https://codereview.chromium.org/2080243002/diff/80001/third_party/WebKit/Sour...
> > > third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp:340:
face =
> > hb_face_create(faceBlob.get(), 0);
> > > Instead of 0, you need the TTC index of the face.  Does Skia have that
> > readily?
> > 
> > The parameter to open stream is an out parameter. More correctly, i should
> > specify a nullptr there since we're not interested in it, but:
> > 
> >      *  If ttcIndex is not null, it is set to the TrueTypeCollection index
> >      *  of this typeface within the stream, or 0 if the stream is not a
> >      *  collection.
> 
> I'm not very familiar with either API, but SkTypeface::openStream() returns a
TTC index, and hb_face_create() wants one - don't we just need to pass the
former to the latter?  I.e.
> 
>   int ttcIndex;
>   SkStreamAsset* typefaceStream = typeface->openStream(&ttcIndex);
>   ...
>       face = hb_face_create(faceBlob.get(), ttcIndex);

Ugh, yes, that is probably it, thank you! Disregard my previous comment, I blame
it on post midsummer Monday morning sleepiness. I'll try with what you're
suggesting. It makes a lot more sense.

[drott, 2016-06-27 17:59:39]

Transfer ttc index to HB

[drott, 2016-06-27 17:59:51]

The CQ bit was checked by drott@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-27 18:00:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[behdad, 2016-06-27 18:13:47]

lgtm w ttc fix.

[commit-bot: I haz the power, 2016-06-27 19:22:33]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-27 19:22:35]

Dry run: This issue passed the CQ dry run.

[drott, 2016-06-27 19:54:36]

The CQ bit was checked by drott@chromium.org

[drott, 2016-06-27 19:54:37]

The patchset sent to the CQ was uploaded after l-g-t-m from eae@chromium.org,
kulshin@chromium.org
Link to the patchset: https://codereview.chromium.org/2080243002/#ps100001
(title: "Transfer ttc index to HB")

[commit-bot: I haz the power, 2016-06-27 19:55:26]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-27 20:01:07]

Description was changed from

==========
Zero-copy font table access for HarfBuzz

Our previous implementation relied on the copy function
harfBuzzSkiaGetTable() to create a font table copy, which is held by
hb_face_t and hb_font_t in turn. This allocation is additional overhead
in terms of memory consumption and allocation cost.

Using Skia's openStream() API we can retrieve the SkStreamAsset for the
SkTypeface. On desktop Linux, on Android and on Windows my
experimentation shows that this SkStreamAsset is available from memory
most of the time and calling getMemoryBase() returns a valid
address. The openStream() call itself duplicates and SkStream
internally, but does not duplicate the underlying in-memory data.

From The SkStreamAsset we can wrap the font data into an hb_blob_t for
consumption by hb_face_create. openStream() transfers ownerships of the
returned SkStreaAsset to the caller, so we have to specifiy a
destruction function to HarfBuzz when hb_face_t releases the hb_blob_t.

This CL saves all time and space for additional table allocations
required for text shaping, which can range from a few kilobytes for a
set of Latin fonts to hundreds of kilobytes for multiple fonts with
large tables accessed by HarfBuzz.

BUG=621878
==========

to

==========
Zero-copy font table access for HarfBuzz

Our previous implementation relied on the copy function
harfBuzzSkiaGetTable() to create a font table copy, which is held by
hb_face_t and hb_font_t in turn. This allocation is additional overhead
in terms of memory consumption and allocation cost.

Using Skia's openStream() API we can retrieve the SkStreamAsset for the
SkTypeface. On desktop Linux, on Android and on Windows my
experimentation shows that this SkStreamAsset is available from memory
most of the time and calling getMemoryBase() returns a valid
address. The openStream() call itself duplicates and SkStream
internally, but does not duplicate the underlying in-memory data.

From The SkStreamAsset we can wrap the font data into an hb_blob_t for
consumption by hb_face_create. openStream() transfers ownerships of the
returned SkStreaAsset to the caller, so we have to specifiy a
destruction function to HarfBuzz when hb_face_t releases the hb_blob_t.

This CL saves all time and space for additional table allocations
required for text shaping, which can range from a few kilobytes for a
set of Latin fonts to hundreds of kilobytes for multiple fonts with
large tables accessed by HarfBuzz.

BUG=621878
==========

[commit-bot: I haz the power, 2016-06-27 20:01:09]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-06-27 20:02:33]

Description was changed from

==========
Zero-copy font table access for HarfBuzz

Our previous implementation relied on the copy function
harfBuzzSkiaGetTable() to create a font table copy, which is held by
hb_face_t and hb_font_t in turn. This allocation is additional overhead
in terms of memory consumption and allocation cost.

Using Skia's openStream() API we can retrieve the SkStreamAsset for the
SkTypeface. On desktop Linux, on Android and on Windows my
experimentation shows that this SkStreamAsset is available from memory
most of the time and calling getMemoryBase() returns a valid
address. The openStream() call itself duplicates and SkStream
internally, but does not duplicate the underlying in-memory data.

From The SkStreamAsset we can wrap the font data into an hb_blob_t for
consumption by hb_face_create. openStream() transfers ownerships of the
returned SkStreaAsset to the caller, so we have to specifiy a
destruction function to HarfBuzz when hb_face_t releases the hb_blob_t.

This CL saves all time and space for additional table allocations
required for text shaping, which can range from a few kilobytes for a
set of Latin fonts to hundreds of kilobytes for multiple fonts with
large tables accessed by HarfBuzz.

BUG=621878
==========

to

==========
Zero-copy font table access for HarfBuzz

Our previous implementation relied on the copy function
harfBuzzSkiaGetTable() to create a font table copy, which is held by
hb_face_t and hb_font_t in turn. This allocation is additional overhead
in terms of memory consumption and allocation cost.

Using Skia's openStream() API we can retrieve the SkStreamAsset for the
SkTypeface. On desktop Linux, on Android and on Windows my
experimentation shows that this SkStreamAsset is available from memory
most of the time and calling getMemoryBase() returns a valid
address. The openStream() call itself duplicates and SkStream
internally, but does not duplicate the underlying in-memory data.

From The SkStreamAsset we can wrap the font data into an hb_blob_t for
consumption by hb_face_create. openStream() transfers ownerships of the
returned SkStreaAsset to the caller, so we have to specifiy a
destruction function to HarfBuzz when hb_face_t releases the hb_blob_t.

This CL saves all time and space for additional table allocations
required for text shaping, which can range from a few kilobytes for a
set of Latin fonts to hundreds of kilobytes for multiple fonts with
large tables accessed by HarfBuzz.

BUG=621878

Committed: https://crrev.com/264e1435dc66fbc7029d5472f334d185d70aea49
Cr-Commit-Position: refs/heads/master@{#402262}
==========

[commit-bot: I haz the power, 2016-06-27 20:02:36]

Patchset 6 (id:??) landed as
https://crrev.com/264e1435dc66fbc7029d5472f334d185d70aea49
Cr-Commit-Position: refs/heads/master@{#402262}

[drott, 2016-06-27 20:02:41]

On 2016/06/27 at 20:01:09, commit-bot wrote:
> Committed patchset #6 (id:100001)

Great! Thanks for your help, fmalita@ and behdad@.