[poppler] Poppler too slow when compiled with cms

[Albert Astals Cid]

A Dimarts 20 Gener 2009, Koji Otani va escriure:
> I made a patch for this problem and attached it.
> Please try and check it.

Good work!

If noone disagrees i'll commit it on next weekend.

Albert

>
> (1) It caches last 5 GfxICCBasedColorSpace.
> (2) It shares GfxColorTransform objects not GfxICCBasedColorSpace, and
> the cache holds copies of GfxICCBasedColorSpace.
> (3) GfxColorTransform objects are reference counted before this patch.
> (4) To check if two ICCBasedColorSpace are same, it uses number and
>     generation of ICCProfile Stream (PDF) Objects.
>     Please note that stream object must be indirect object.
> ------------
> Koji Otani
>
> From: Albert Astals Cid <aacid at kde.org>
> Subject: Re: [poppler] Poppler too slow when compiled with cms
> Date: Mon, 19 Jan 2009 20:00:39 +0100
> Message-ID: <200901192000.40478.aacid at kde.org>
>
> aacid> A Dilluns 19 Gener 2009, Koji Otani va escriure:
> aacid> > From: Albert Astals Cid <aacid at kde.org>
> aacid> > Subject: Re: [poppler] Poppler too slow when compiled with cms
> aacid> > Date: Sun, 18 Jan 2009 20:25:03 +0100
> aacid> > Message-ID: <200901182025.03909.aacid at kde.org>
> aacid> >
> aacid> > aacid> A Diumenge 18 Gener 2009, Carlos Garcia Campos va escriure:
> aacid> > aacid> > when compiled with cms support enabled poppler is too
> slow when aacid> > aacid> > rendering some pages. For example, rendering
> page 831 of PDF aacid> > aacid> > Specification 1.7 takes more than 1
> minute in my system. aacid> > aacid> >
> aacid> > aacid> > Koji, any idea why does it happen?
> aacid> > aacid>
> aacid> > aacid> I think the problem is that in this page there's a Pattern,
> our aacid> > slowest code, aacid> that forces the creation of 272
> GfxICCBasedColorSpaces aacid> > that isn't fast aacid> either, but the
> problem is not the aacid> > GfxICCBasedColorSpaces itself, the problem
> aacid> is that the pattern aacid> > implementation sucks.
> aacid> > aacid>
> aacid> > aacid> To try to bypass this problem we could try implement a kind
> of cache aacid> > for aacid> GfxColorSpace so you don't have to recreate
> one if is the same aacid> > as one of the aacid> last N (1-5). This has
> several implications, like aacid> > adding refcounting to aacid>
> GfxColorSpace and finding how to know if we aacid> > are asked for the same
> aacid> GfxColorSpace.
> aacid> > aacid>
> aacid> >
> aacid> > I think you are right.
> aacid> > I did quick hack to test only this case. It caches
> aacid> >  a last GfxICCBasedColorSpace.
> aacid> >
> aacid> >   It created only 3 GfxICCBasedColorSpaces for rendering the page.
> aacid> >   It took 2 seconds. (before hack, it took 140 seconds)
> aacid>
> aacid> Can we see the patch? Maybe we can improve it a bit or use it
> directly. aacid>
> aacid> Albert
> aacid>
> aacid> >
> aacid> > -----------------
> aacid> > Koji Otani
> aacid> >
> aacid> _______________________________________________
> aacid> poppler mailing list
> aacid> poppler at lists.freedesktop.org
> aacid> http://lists.freedesktop.org/mailman/listinfo/poppler