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