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

Wed Jan 12 08:52:35 PST 2011

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

>> Thomas
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
>
> .
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: radialsh.patch
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20110112/aecf7d19/attachment-0001.txt>