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

Sat Jan 15 08:01:56 PST 2011

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

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

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