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

Sun Jan 16 10:01:38 PST 2011

Am 15.01.2011 17:01, schrieb Thomas Freitag:
> Am 13.01.2011 21:55, schrieb Albert Astals Cid:
>> A Dimecres, 12 de gener de 2011, Thomas Freitag va escriure:
>>> Am 09.01.2011 23:48, schrieb Albert Astals Cid:
>>>> A Diumenge, 9 de gener de 2011, Thomas Freitag va escriure:
>>>>> Am 08.01.2011 00:56, schrieb Albert Astals Cid:
>>>>>> A Dilluns, 3 de gener de 2011, Thomas Freitag va escriure:
>>>>>>> Am 03.01.2011 00:28, schrieb Albert Astals Cid:
>>>>>>>> A Diumenge, 2 de gener de 2011, Thomas Freitag va escriure:
>>>>>>>>> Am 01.01.2011 22:34, schrieb Albert Astals Cid:
>>>>>>>>>> A Dissabte, 1 de gener de 2011, Thomas Freitag va escriure:
>>>>>>>>>>> Please regtest this new patch. What I've done in the meantime:
>>>>>>>>>>>
>>>>>>>>>>> a) speed up the implemenation but have enough quality left.
>>>>>>>>>>> b) implement the shading extend in a correct way, test it 
>>>>>>>>>>> against
>>>>>>>>>>> the samples from the PDF spec (appendix L)
>>>>>>>>>>> c) test it against all samples from Andrea, including bug 
>>>>>>>>>>> 32349&
>>>>>>>>>>> 30887. d) test it against ducks&      roses and all the PDF You
>>>>>>>>>>> send me because of regressions with former patches.
>>>>>>>>>>>
>>>>>>>>>>> So I'm think I'm quite near of finishing the implementation, 
>>>>>>>>>>> just
>>>>>>>>>>> waiting for the result of Your regtest.
>>>>>>>>>> There are a few empty pixels in the border of
>>>>>>>>>> http://bugsfiles.kde.org/attachment.cgi?id=20680
>>>>>>>>> Sorry, I made such a lot changes in the last three days, that I
>>>>>>>>> forgot to remove a test case where I wanted to see where normal
>>>>>>>>> shading stops and extending shading starts, so the last circle of
>>>>>>>>> normal shading was no more painted :-(
>>>>>>>>>
>>>>>>>>> Please try the new patch.
>>>>>>>> There is a regression on page 25 of
>>>>>>>> http://download.tuxfamily.org/magnum/doc/magnum04.pdf
>>>>>>>>
>>>>>>>> See attached files.
>>>>>>> This was not really a bug in the new feature "radial shading": 
>>>>>>> when I
>>>>>>> introduced the dynamic pattern in axial shading, and the ability to
>>>>>>> return gFalse in getColor() if nothing should be paint, I forgot to
>>>>>>> increase some pipe pointers in pipeRun, i.e. if softmask is used 
>>>>>>> the
>>>>>>> softmask pointers must be increased, too.
>>>>>>>
>>>>>>> Please try the new patch.
>>>>>>>
>>>>>>> BTW, Albert: I start working again, and because this is almost a
>>>>>>> private pleasure, I can probably look only on weekend into new
>>>>>>> regressions. And because I think we are really quite near, could 
>>>>>>> You
>>>>>>> please run the regression test over all PDF and send me them all or
>>>>>>> links to it instead stopping the test if You first regression? 
>>>>>>> Then I
>>>>>>> can look at all regressions next weekend...
>>>>> It seems as if I was a little bit to optimistic:
>>>>>> The image generated by the new implementation is still considerably
>>>>>> "blockier" than the generated by the old one in page 25 of that pdf.
>>>>> Solved, and the new routines are faster!
>>>>>
>>>>>> There is a regression in page 8 of
>>>>>> http://launchpadlibrarian.net/17355619/2008SPYSupplement.pdf
>>>>> Solved, new and old routines need nearly the same time
>>>>>
>>>>>> There is a regression on the top left bubble of
>>>>>> https://bugs.freedesktop.org/attachment.cgi?id=32823
>>>>> Solved, new and old routines need nearly the same time.
>>>>>
>>>>>> There is a regression in the alfa romeo logo of one of the files you
>>>>>> sent for https://bugs.freedesktop.org/show_bug.cgi?id=27482 (if you
>>>>>> don't have it anymore ask and i'll send it to you)
>>>>> Solved, new and old routines need nearly the same time.
>>>>>
>>>>>> The pdf at https://bugs.freedesktop.org/attachment.cgi?id=40344 
>>>>>> turned
>>>>>> to grayscale
>>>>> Solved, new and old routines need nearly the same time.
>>>>>
>>>>>> https://bugs.freedesktop.org/attachment.cgi?id=41060 looks really
>>>>>> blocky too with the new patch
>>>>> Better, but still a little bit blockier. Seems to be the Bresenham
>>>>> routines.
>>>>>
>>>>>> https://bugs.freedesktop.org/attachment.cgi?id=6858 is considerably
>>>>>> slower with the new patch than with the old code (takes more than 
>>>>>> the
>>>>>> six times the old code and then stopped trying so no sure if the
>>>>>> rendering is
>>>>>> better/worse/the same)
>>>>> I've optimized it, but I still need a little bit less than six times
>>>>> than with the old routines. Reason for this (a PDF with round 
>>>>> about 600
>>>>> radial shadings!) are some radial shadings with a radius of more than
>>>>> 10.000.00 pts and then pick a partial square with 256 pts. With
>>>>> Bresenham I have to calculate als the 10.000.000 circle points 
>>>>> before I
>>>>> can intersect :-(
>>>>>
>>>>>> There is another circle that got very blocky, i'll send you the 
>>>>>> file.
>>>>> No solution 'til now. It's hard to look into it, it need more than 15
>>>>> minutes on my not so slow laptop for rendering until it reaches the
>>>>> first radial shading, so I give up for today.
>>>>>
>>>>> Seems as if I need to spend at least one additional weekend for it. I
>>>>> have an idea to combine old drawing circles with only 66 points 
>>>>> instead
>>>>> of using Bresenham algorithm to get it faster, but I've to make some
>>>>> more tests on this.
>>>>>
>>>>> If You think I can upload a new patch with the actual resuts, just to
>>>>> look for new / other regressions. Otherwise we can of course wait 
>>>>> after
>>>>> I finish it.
>>>> I think i prefer to wait until you have a patch that fixes all the 
>>>> known
>>>> regressions until doing another regression test run.
>>>>
>>>> Thanks :-)
>>>>
>>>> Albert
>>> I think, I'm through. Here the new optimized patch. Now I'm mostly
>>> faster then the old implementation, only when the corrected
>>> implementation of larger extension circle is needed, I need sometimes
>>> more time. See for example the european map You sent me in private,
>>> where the ships were very blocky: with the new implementation this is
>>> solved and  the square around the ships are away (which is correct, 
>>> they
>>> should not be there!). Even in the corrected implementation of larger
>>> extension circles I made a lot of optimization steps, see i.e.
>>> https://bugs.freedesktop.org/attachment.cgi?id=41506 from Andrea, which
>>> is now rendered correctly and in time. I'm also able to render now the
>>> PDFs in http://people.freedesktop.org/~ranma42/cairo/radial/ from
>>> Andrea, I think, I found a good compromise between speed and quality 
>>> there.
>>> Only https://bugs.freedesktop.org/attachment.cgi?id=41060 still looks a
>>> little bit uglier (blockier) than with the old routines, but because
>>> this is more or less an artificial radial shading, I would accept this
>>> case. What are You thinking about that?
>>> Last but not least, even if You'll find new regressions with the new
>>> patch, I want really to thank Andrea Canciani for his samples. Not only
>>> that it's easier testing complete new code with PDF files, which only
>>> contain radial shadings and nothing else, they also gives me a deeper
>>> understanding how radial shading is specified in comparision what I
>>> understood reading the Adobe PDF spec.
>>>
>>> Please test the new patch,
>> It dies with a "Bogus memory allocation size" in
>> https://bugs.kde.org/attachment.cgi?id=27458
> 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.
>
> Please test this patch, sorry if I boring You sending one patch after 
> another,
> Thomas
Please don't wonder that I upload once again a patch for radial shading. 
Before You try this one, please finish first regtesting the patch from 
yesterday.
When I worked on implementing radial shading, I already thought that it 
should be possible directly get the color from the radial shading object 
having just the x,y-position, without having any other tools. But i 
wasn't sure, so I wanted to finish the implementation with the bitmap as 
tool first.
Today early morning I started  to "undef" the bitmap tools and 
implementing the direct way. And as You see now, I succeed, and it 
dramatically speed up rendering and quality in almost every PDF I 
tested. Only when there is a huge bitmap in which a huge radial shading 
should be placed, I need more time. One example for this poorer speed is 
once again the ducks & roses: Even if You don't see that, the most 
shadings there are done in a bitmap of 16384 pts and then downscaled. So 
with this special PDF (and it was the only one where this happens in my 
tests), rendering needs now approximately the double amount of time. In 
every other case I was at least as fast as before, having a better 
quality (i.e. the magnum.pdf, the small white circles are gone now and 
we have a smooth shading, really comparable what the acrobat does). And 
last but not least: I render Andrea's PDF (the non reduced one, where 
acrobat gives up), in round about 25 seconds in high quality.
Even with this enhancements, I kindly ask You to finish regtesting the 
former patch and let the "undef"ed code from this patch in, after it 
runs through Your regression test, too. Reason for this request is, that 
in case of futur regressions in radial shading I can easily insert it 
again and can determine where the colors are differnt with these two 
methods.

Thanks a lot in advance,
Thomas
>
>> Albert
>>
>>> Thomas
>>>
>>>>> Thomas
>>>> _______________________________________________
>>>> poppler mailing list
>>>> poppler at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>>>
>>>> .
>> _______________________________________________
>> poppler mailing list
>> poppler at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/poppler
>>
>> .
>>
>
>
> _______________________________________________
> 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/20110116/118b456a/attachment-0001.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: radialsh.patch
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20110116/118b456a/attachment-0001.txt>