[poppler] Poppler too slow when compiled with cms

Albert Astals Cid aacid at kde.org
Sun Jan 18 11:25:03 PST 2009


A Diumenge 18 Gener 2009, Carlos Garcia Campos va escriure:
> when compiled with cms support enabled poppler is too slow when
> rendering some pages. For example, rendering page 831 of PDF
> Specification 1.7 takes more than 1 minute in my system.
>
> Koji, any idea why does it happen?

I think the problem is that in this page there's a Pattern, our slowest code, 
that forces the creation of 272 GfxICCBasedColorSpaces that isn't fast 
either, but the problem is not the GfxICCBasedColorSpaces itself, the problem 
is that the pattern implementation sucks.

To try to bypass this problem we could try implement a kind of cache for 
GfxColorSpace so you don't have to recreate one if is the same as one of the 
last N (1-5). This has several implications, like adding refcounting to 
GfxColorSpace and finding how to know if we are asked for the same 
GfxColorSpace.

Also sometime somewhen we need someone to sit down and kill the Pattern 
bottleneck.

This is going to take probably some time that goes against Carlos' 
idea/need/will to release a new stable version based on master "soon".

So options:
 * I'm wrong and this is not the cause of the slowdown
 * Someone else has a better idea how to fix this
 * We wait for the solution to land in master and probably release later this 
year (my initial intention)
 * We remove Color Management from master and do a master release soon 

I would vote for 3 as color management seems a nice thing to have imho and 
it's been just 3 months since latest major release.

What are other's opinions here?

Albert


More information about the poppler mailing list