[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compressed streams

From: David Turner
Subject: Re: compressed streams
Date: Fri, 18 Sep 2020 13:18:35 +0200

Le jeu. 17 sept. 2020 à 14:01, Werner LEMBERG <> a écrit :

> These are some horrible numbers that essentially test FT_Load_Glyph
> from compressed unifont.pcf.gz in reverse order: [...]
> real    0m6.062s
> The same string forward is much faster: [...]
> real    0m0.486s


> Is it well known that rewinding the compressed stream is so
> prohibitively expensive?  Or, is this a bug?

I don't know, sorry.  The basic question is, I guess, whether we are
correctly using the gzip interface ...

We do, there is no "rewinding the compressed stream", we have to restart from the first byte of the file everytime we need to go back in the file.
We just didn't implement some sort of caching or state checkpointing in the gzip decoder because this kind of font is legacy and has better alternatives now (see vs for Debian)..

But in case one would really want to support this, it is possible to improve random access in gzip stream by essentially storing the state of the deflate decoder at various points of the input file. For a practical example, see:

So in theory, something like that could be added. It's just seems a lot of complexity for little practical benefits imho.

- David


reply via email to

[Prev in Thread] Current Thread [Next in Thread]