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

[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

Albert

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