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

[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

> 
> Thomas