Le jeu. 17 sept. 2020 à 14:01, Werner LEMBERG <w...@gnu.org> 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 > > Ouch. > > > 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 https://packages.debian.org/fr/sid/xfonts-unifont vs https://packages.debian.org/fr/sid/fonts-unifont 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: https://github.com/madler/zlib/blob/2fa463bacfff79181df1a5270fb67cc679a53e71/examples/zran.c So in theory, something like that could be added. It's just seems a lot of complexity for little practical benefits imho. - David > > Werner > >
