Re: Try time (decode) and size for null glyf/loca xform vs regular vs woff1

The reference implementation just always does it as that seems to be what
the spec says. We could potentially do something like make that optional
and flip it off in OTS I suppose?

On Thu, May 19, 2016 at 1:36 PM, Behdad Esfahbod <behdad@google.com> wrote:

> On Thu, May 19, 2016 at 9:00 AM, Roderick Sheeter <rsheeter@google.com>
> wrote:
>
>> As requested in https://www.w3.org/Fonts/WG/track/actions/186 I ran a
>> variety of compress/decompress scenarios over the Google Fonts collection.
>>
>> Main findings are:
>>
>>  * WOFF2 decompression uses less memory than woff, more than brotli
>> standalone.
>>
>>  * WOFF2 decompression was faster than WOFF at min, median, and average
>> but has a higher standard deviation and max.
>>
>>  * Applying brotli (using the "bro" utility; https://github.com/
>> google/brotli/blob/master/tools/bro.cc) directly to a font (to simulate
>> use via Accept-Encoding: br) resulted in a file that was larger than a
>> transformed woff2 but fastest to decompress.
>>
>>  * WOFF2 decompression is slightly faster when there are no transforms.
>> The most significant improvement is lower standard deviation and worst-case
>> time.
>>
>> The brotli codebase is probably the most carefully optimized of the
>> implementations I compared. WOFF2 without transform could likely be sped
>> up, though some work is hard to dodge without violating the spec. For
>> example, "the decoder MUST recalculate the checkSum value for each decoded
>> table."
>>
>
> But, browsers surely are allowed to skip that if they know the font will
> still work equally well.
>
>
>> Summary and raw results can be seen in https://docs.google.com/
>> spreadsheets/d/1_ZYTFaG6_NJy7n_t-RpPDXCAZIKDP_1SXiJQz0o8QMg/edit#gid=
>> 367643030.
>>
>> Cheers, Rod S.
>>
>
>