[HarfBuzz] On hb_shape_plan() and other API for 1.0
behdad at behdad.org
Wed Apr 11 18:47:35 PDT 2012
As a crude test, I profiled the Indic shaping, and am conjecturing that about
10 to 20 percent of the time can be saved pre-planning the shaping process.
My testing showed no measurable saving for skipping the sanitizing process.
Maybe both can wait (and not block a 1.0 release) since neither one seems to
be hugely effective.
On 04/10/2012 09:48 PM, Behdad Esfahbod wrote:
> Hi list,
> As we get closer to a 1.0 release of harfbuzz-ng, I thought I put out there
> API questions that are still open, hoping that we can come to a conclusion
> before the HarfBuzz hackfest in May. So here we go.
> - Sanitize API: I'm not sure how critical this is. Conceptually, the main use
> of this API is to make fontconfig call hb_sanitize() (or whatever it ends up
> being called) and cache the results, such that clients using that information
> can tell HarfBuzz when a font file is /clean/ and hence can skip sanitize
> process. It's purely an optimization, and hence without numbers, I'm hesitant
> to pursue it since I'm not sure about the API itself and how that plays with
> logic changes between versions.
> - hb_shape_plan(): Currently, every time you call hb_shape(), we compile the
> list of lookups and sort through them. This process is independent of the
> text being shaped and hence can be cached. The big issue on the table is that
> this process *is* dependent on the font features being enabled and their
> values, but not the exact cluster ranges for those features.
> In the past, I was thinking about a hb_shape_plan() and
> hb_shape_plan_execute() or hb_shape_planned() that would take the computed
> plan, text, and features, and do the shaping faster. However, my main issue
> with that API is that it's extremely error-prone for people to use a plan with
> different features than those used to build the plan. So today I had this
> idea of allow pre-planning only for when there are no user features. Ie.
> whereas we currently have:
> hb_shape (hb_font_t *font,
> hb_buffer_t *buffer,
> const hb_feature_t *features,
> unsigned int num_features);
> The proposed API will add:
> hb_shape_plan_t *
> hb_shape_plan (hb_font_t *font,
> hb_segment_properties_t *props);
> hb_shape_planned (hb_shape_plan *plan,
> hb_buffer_t *buffer);
> hb_shape_plan_destroy (hb_shape_plan_t *plan);
> This would expose the currently unexposed hb_segment_properties_t type which
> is simply a tuple of script, language, and direction.
> If going ahead with this, we need to figure out the hb_shape_full() parallel also.
> Comments? Any other API bits I'm missing?
More information about the HarfBuzz