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 _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
