Re: Announcing new font compression project

On Mon, Apr 2, 2012 at 9:11 AM, Chris Lilley <chris@w3.org> wrote:

> On Friday, March 30, 2012, 11:26:57 PM, Thomas wrote:
>
> TP> It will be interesting to see the trade-off of compression gains
> TP> versus performance analyzed in detail. Will the ideal tradeoff be
> TP> different for mobile devices? They have both (often) lower bandwidth
> TP> and usually less powerful CPUs, upping the stakes for finding the
> TP> sweet spot in that tradeoff.
>
> Good point.
>

I've started this analysis, but don't have hard benchmark data on mobile
devices yet. My _guess_ is that LZMA will be the sweet spot for mobile too,
as CPU's are rapidly approaching a good fraction of desktop performance,
while data speeds still lag.


> Some compression schemes are asymmetric (take more effort to compress, but
> are easier to decompress) - zlib is one of those. This makes sense for
> content delivery because the compression happens once and the decompression
> happens multiple times. Where is LZMA on that?
>

A quick test over some font data in a 64-bit Linux environment shows that
LZMA compression is about 13 times slower than decompression (the
corresponding ratio for gzip is about 3.6:1). Thus, it is most suitable for
environments where the data to be served is computed in advance. This is
one reason why the proposed format also includes zlib as an option - for
highly dynamic serving, it may offer a lower end-to-end latency than LZMA.


> Some compression schemes are CPU intensive while others work best with a
> large amount of memory. Some need a fixed minimum buffer size while others
> are adaptable (will work, but slower, with limited memory).
>
> Another tradeoff that occurs to me is that with classic WOFF, tables that
> are not needed do not have to be decompressed (and in theory do not even
> have to be downloaded, if client and server support byte ranges, although I
> haven't seen that implemented for WOFF). With the new proposal, if the
> option is taken to use one compression stream for all tables, that
> advantage is lost. Perhaps there might be best practices on which sets of
> tables to compress together (which in turn requires info on which tables
> are used by various platforms).


The win is not clear. I know of no implementations that do per-table
decompression currently - and there are significant other downsides to
doing so. Byte range requests may interact badly with caching. Further, to
do byte range requests requires sequential HTTP requests, which will
typically increase overall latency (unless the savings in file size is
significant). Also, in most fonts the bulk of the data is in the glyf
table, including, for example, most of the hinting data.

All that said, the format definitely still supports per-table compression,
so if the need arises it is supported.

 --
>  Chris Lilley   Technical Director, Interaction Domain
>  W3C Graphics Activity Lead, Fonts Activity Lead
>  Co-Chair, W3C Hypertext CG
>  Member, CSS, WebFonts, SVG Working Groups
>
>
>