<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>