<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - very slow render"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=64892#c23">Comment # 23</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - very slow render"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=64892">bug 64892</a>
              from <span class="vcard"><a class="email" href="mailto:Thomas.Freitag@alfa.de" title="Thomas Freitag <Thomas.Freitag@alfa.de>"> <span class="fn">Thomas Freitag</span></a>
</span></b>
        <pre>(In reply to <a href="show_bug.cgi?id=64892#c22">comment #22</a>)
<span class="quote">> Thomas the question about the delete line is if it belongs to the same
> bugfix or not. I.e. if we were not going to commit this, do we still need
> the delete? I understand we do, thus is part of a different bugfix.</span >

Yep. We need the delete in either case.

<span class="quote">> 
> I'll try to see why lcms is so slow, i think the lcms is being parsed all
> the times for the tiling</span >

Seems to be important for You before testing my patch, therefore I made some
tests by my own, here my results, hopefully You come to the same conclusion:

with lcms2:

time utils/pdftoppm -cropbox -png -r 72 -f 35 -l 35 zgewinne\ und\
Entlastungen\ öffentlicher\ Haushalte\ durch\ Public\ Private\ Partnership\
\(PPP\).cracked.pdf zgewinne

real    0m16.479s
user    0m16.321s
sys    0m0.104s

(so Your computer is faster than mine :-) )

with lcms1:

time utils/pdftoppm -cropbox -png -r 72 -f 35 -l 35 zgewinne\ und\
Entlastungen\ öffentlicher\ Haushalte\ durch\ Public\ Private\ Partnership\
\(PPP\).cracked.pdf zgewinne

real    0m4.424s
user    0m4.332s
sys    0m0.056s

(that's what I expected because of the lcms discussion in the poppler
community)

Then I made a valgrind profile:
We have 2639 calls of tilingPatternFill, where the tiling pattern contains an
image in GfxIndexedColorSpace (parse of it is called 2639 times) which base
colorspace is a GfxICCBasedColorSpace (parse of it is called 2640 times). And
because this colorspace is not cached (not sure, if this is possible, I haven't
looked into the PDF itself, but I can't believe that we really have 2639
different images with different colormaps), a new lcms transformation has to be
constructed, and that costs the time.

Kidding: isn't that another bug, too, and You're hijacking this bug :-) ?
(Okay, okay, this behaviour makes the rendering slow, too!)</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>