[poppler] Slow rendering of file with Type3 fonts

[Jiri Klement]

Hi,

I've investigated a bit more and here are the results. So far it seems
that poppler code is correct. Problem is in pdf file, which declares
much bigger FontBBox than it actualy needs.

It can be made much faster by using bounding box specified by d1
command instead of \FontBBox. But I'm not sure if caching of font
glyphs is neccessary. When I disabled it (by commenting out
SplashOutputDev::type3D1) the pdf file is shown instantly. Even in
valgrind emulation it runs quite fast.

I can try to write a patch, but I'm not sure which way use to fix this.

On 12/18/07, Brad Hards <bradh at frogmouth.net> wrote:
> On Wednesday 19 December 2007 04:39:39 am Jiri Klement wrote:
> > Hi,
> G'day Jiri,
>
> > Rendering of file http://home.zcu.cz/~jklement/spolehlivost.pdf is
> > very slow using poppler with splash backend. (current version from
> > CVS). It takes about 6 seconds to render one page. I've profiled
> > poppler using valgrind and kcallgrind  to find out what takes so long.
> Do you mean with "current version from git"?
>
> I tried it, and I'm not seeing 6 seconds. It does take a few seconds.
> I haven't actually investigated it properly, but I do see a few of these:
> Error: Bad bounding box in Type 3 glyph
>
> > It seems that poppler first convert Type3 fonts to bitmaps and then
> > print them to the screen. But bounding box for fonts in this file is
> > 1000x1000 which makes drawing font bitmaps very slow. KCallGrind shows
> > that poppler spends 95% of time in Splash::fillGlyph2. Why don't
> > poppler prints Type3 fonts directly?
> Any chance of a patch?
>
> > Another suspicious thing is number of calls of SplashClip::test. Only
> > partialy clipped characters should call SplashClip::test, but it seem
> > that they're incorrectly detected. I think rect of glyph in glyph
> > space is compared with SplashClip in world space. Poppler spends 25%
> > of time in method SplashClip::test.
> Again, any chance of a patch?
>
> Thanks for the investigative work.
>
> Brad
>