Map in-memory font tables to HarfBuzz without copies |
||
Issue descriptionAs discussed and filed in skia:5387, Blink's memory usage would profit from avoiding copies of font table data that is already held in memory. After investigating this in-depth and looking at the Skia/FreeType code, it turns out this is possible on most platforms and in most cases without API changes in Skia, using the openStream() and getMemoryBase(). If the returned SkStreamAsset is not one that can return a memory base address, we can fall back to instantiating a hb_face_t which does table copies.
,
Jun 21 2016
,
Jun 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/264e1435dc66fbc7029d5472f334d185d70aea49 commit 264e1435dc66fbc7029d5472f334d185d70aea49 Author: drott <drott@chromium.org> Date: Mon Jun 27 20:00:53 2016 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 Review-Url: https://codereview.chromium.org/2080243002 Cr-Commit-Position: refs/heads/master@{#402262} [modify] https://crrev.com/264e1435dc66fbc7029d5472f334d185d70aea49/third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp
,
Jun 27 2016
,
Jun 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/85934478433c6484b352e348f149e5e256be04d3 commit 85934478433c6484b352e348f149e5e256be04d3 Author: drott <drott@chromium.org> Date: Wed Jun 29 11:34:17 2016 Add UMA for hb_face_t instantiation type Counting on non-Mac platforms what kind of hb_face_t instantiation method is used and whether the in-place access was successful. The goal is to identify whether we need the fallback codepath at all. BUG= 621878 Review-Url: https://codereview.chromium.org/2088183002 Cr-Commit-Position: refs/heads/master@{#402779} [modify] https://crrev.com/85934478433c6484b352e348f149e5e256be04d3/third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp [modify] https://crrev.com/85934478433c6484b352e348f149e5e256be04d3/tools/metrics/histograms/histograms.xml
,
Jun 29 2016
|
||
►
Sign in to add a comment |
||
Comment 1 by drott@chromium.org
, Jun 21 2016Labels: -Pri-3 OS-Android OS-Linux OS-Windows Pri-2