[poppler] Followup Bug 32349 & Poppler: More shading fun ;-)

[Thomas Freitag]

Am 24.01.2011 21:44, schrieb Andrea Canciani:
> On Sun, Jan 23, 2011 at 9:36 PM, Albert Astals Cid<aacid at kde.org>  wrote:
>> A Diumenge, 23 de gener de 2011, Thomas Freitag va escriure:
>>> Am 23.01.2011 18:12, schrieb Albert Astals Cid:
>>>> A Dissabte, 15 de gener de 2011, Thomas Freitag va escriure
>>>>
>>>>> The memory problems were coming still from the wrong calculation of
>>>>> shading extension which I took from Gfx.cc and tried to correct, but it
>>>>> still leaded to huge circles. Andrea gave me a hint of a correct
>>>>> calculation of radial shading extension in cairo, and I adapated that
>>>>> code piece now successfully to Splash. It seems, as if with this the
>>>>> memory problems are now gone, at least I could render every PDF You sent
>>>>> me in the past, and I couldn't find any regressions in the rendering
>>>>> results.
>>>> I got a new regression, will send you privately the pdf file.
>>>>
>>>> The question now is, you want me to try the other newest patch? Or you
>>>> want to fix this "old" one?
>>> Please test the newest patch. It has a completely other algorithm and as
>>> I already tested, it has not this regression and hopefully no other. I
>>> 'll answer the other mails in a few seconds.
>> Ok, i'll run the regtest on that.
> If that passes the regtest, this patchset should pass it as well.
>
> 0001, 0002 and 0003 are fixes and cleanups for poppler Functions.
>
> 0004 abstracts a common interface from axial and radial shadings
>
> 0005 is not completely clear to me. I think it forces antialiasing to be
> applied on shadings.
>
> In 0006 I cleaned up the radial implementation by Thomas. In particular
> I simplified the code which chooses one of the two solutions.
>
> 0007 const-ifies Matrix methods and adds norm() and determinant().
>
> 0008 adds simple caching (with uniform sampling) with a number of
> samples which depends on the shading extents. It guarantees correct
> rendering and provides much better performance than an hardcoded
> constant (for example 65536 caused performance regressions with
> respect to no caching at all in the ducks&roses pdf).
> I left in some debugging code which is helpful while testing the
> performance, because it prints the cache size extimate and if the cache
> was activated or not.
>
> 0009 improves the parameter range estimate (in 0007 it is assumed to be
> the full range). This might provide a speedup in some very particular
> pdf files, but so far I haven't found any in which it actually matters.
Fantastic!!!!!!!!!!
I just applied the patches because I was full of curiosity. Two examples
a) ducks and roses is now rendered in less than half of time in 
comparison without any radial shading patches, and in less than a 
quarter of the time I needed with my patch.
b) rendering the non reduced PDF where acrobat gives up is done now in a 
few seconds, and in 2/3 I need with the radial patch.
So the speed optimization is really great!

I had only a small problem compiling it with visual studio under 
windows: the c-compiler has a problem with using std::min or std::max, 
s. i.e. http://heifner.blogspot.com/2008/02/stdmin-and-stdmax.html, so I 
defined

#undef MIN
#define MIN(a, b) ((a) < (b) ? (a) : (b))
#undef MAX
#define MAX(a, b) ((a) > (b) ? (a) : (b))

and used MIN and MAX instead of std::min and std::max. And You should 
remove the fprintf's in GfxState.cc ....

But as You already seen, Albert will probably commit my patch to master 
soon, so it would be very nice, if You can create a new patch after he 
will commit it. Because the basic method (calculation the color given 
the x,y-position) is the same, a regtest with that patch then will 
propably not have such a lot differences and Albert has less work to 
compare the results. And on the other hand I would like to have my patch 
now in and don't like to stop that having a additional ping pong game 
with patches.

Thomas

<http://www.dict.cc/englisch-deutsch/curiosity.html>
> Commit messages and authorship are to be fixed. I haven't implemented
> the non-uniform sampling because I had some problem with clipping
> to the domain and range, but it can be solved and I hope to do it soon.
>
> I'd like to get a confirmation that the cache is working (i.e. it speeds up
> the documents which the radial gradient patch slows down and causes
> no rendering regressions).
> Please remember that this patchset also affects axial shadings, which
> should become faster as well.
>
> Andrea
>
>
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20110125/b8f5dcc6/attachment.html>