Re: Announcing new font compression project

--20cf3074b4ee3c6b2a04bcb814f4
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 2, 2012 at 9:11 AM, Chris Lilley <[email protected]> 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
>
>
>

--20cf3074b4ee3c6b2a04bcb814f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Apr 2, 2012 at 9:11 AM, Chris Li=
lley <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank=
">[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On Friday, March 30, 2012, 11:26:57 PM, Thomas wrote:<br>
<br>
TP&gt; It will be interesting to see the trade-off of compression gains<br>
TP&gt; versus performance analyzed in detail. Will the ideal tradeoff be<br=
>
TP&gt; different for mobile devices? They have both (often) lower bandwidth=
<br>
TP&gt; and usually less powerful CPUs, upping the stakes for finding the<br=
>
TP&gt; sweet spot in that tradeoff.<br>
<br>
Good point.<br></blockquote><div><br></div><div>I&#39;ve started this analy=
sis, but don&#39;t have hard benchmark data on mobile devices yet. My _gues=
s_ is that LZMA will be the sweet spot for mobile too, as CPU&#39;s are rap=
idly approaching a good fraction of desktop performance, while data speeds =
still lag.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
Some compression schemes are asymmetric (take more effort to compress, but =
are easier to decompress) - zlib is one of those. This makes sense for cont=
ent delivery because the compression happens once and the decompression hap=
pens multiple times. Where is LZMA on that?<br>

</blockquote><div><br></div><div>A quick test over some font data in a 64-b=
it Linux environment shows that LZMA compression is about 13 times slower t=
han 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 compute=
d 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.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
Some compression schemes are CPU intensive while others work best with a la=
rge amount of memory. Some need a fixed minimum buffer size while others ar=
e adaptable (will work, but slower, with limited memory).<br>
<br>
Another tradeoff that occurs to me is that with classic WOFF, tables that a=
re not needed do not have to be decompressed (and in theory do not even hav=
e to be downloaded, if client and server support byte ranges, although I ha=
ven&#39;t seen that implemented for WOFF). With the new proposal, if the op=
tion 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 c=
ompress together (which in turn requires info on which tables are used by v=
arious platforms).</blockquote>

<div><br></div><div>The win is not clear. I know of no implementations that=
 do per-table decompression currently - and there are significant other dow=
nsides to doing so. Byte range requests may interact badly with caching. Fu=
rther, to do byte range requests requires sequential HTTP requests, which w=
ill 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.</div>
<div><br></div><div>All that said, the format definitely still supports per=
-table compression, so if the need arises it is supported.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">

<div><div>
--<br>
=A0Chris Lilley =A0 Technical Director, Interaction Domain<br>
=A0W3C Graphics Activity Lead, Fonts Activity Lead<br>
=A0Co-Chair, W3C Hypertext CG<br>
=A0Member, CSS, WebFonts, SVG Working Groups<br>
<br>
<br>
</div></div></blockquote></div><br>

--20cf3074b4ee3c6b2a04bcb814f4--