[poppler] Followup Bug 32349 & Poppler: More shading fun ;-)
Thomas Freitag
Thomas.Freitag at kabelmail.de
Sun Jan 9 14:35:47 PST 2011
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.
Thomas
> Albert
>
>> Thomas
>>
>>> Albert
>>>
>>>> Thomas
>>>>
>>>>> Albert
>>>>>
>>>>>> Happy new year,
>>>>>> Thomas
>>>>>>
>>>>>> Am 31.12.2010 03:10, schrieb Thomas Freitag:
>>>>>>> I made a lot of mistakes, but I'm quite close now, s. attached
>>>>>>> rendering of Andrea's PDF. What is still up to do, is
>>>>>>> a) speed it up again
>>>>>>> b) implement the shading extend in a correct way (I'd already a look
>>>>>>> at it, it's also wrong implemented in Gfx)
>>>>>>> c) run it again through my own regression test.
>>>>>>>
>>>>>>> Thomas
>>>>>>>
>>>>>>> Am 30.12.2010 12:20, schrieb Thomas Freitag:
>>>>>>>> I just recognized a bug with Andrea's PDF when drawing non centered
>>>>>>>> circles. Want to fix that first before sending a new patch.
>>>>>>>>
>>>>>>>> Thomas
>>>>>>>>
>>>>>>>> Am 30.12.2010 11:29, schrieb Albert Astals Cid:
>>>>>>>>> A Dijous, 30 de desembre de 2010, vàreu escriure:
>>>>>>>>>> Sorry, I attached Your "new.png", not mine. Here the correct one
>>>>>>>>>> produced with the above changes.
>>>>>>>>> This looks good enough for me, can you send the full patch to the
>>>>>>>>> list?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> Albert
>>>>>>>>>
>>>>>>>>>> Thomas
>>>>>>>>>>
>>>>>>>>>> Am 30.12.2010 10:31, schrieb Thomas Freitag:
>>>>>>>>>>> Hi Albert!
>>>>>>>>>>>
>>>>>>>>>>> I changed the SplashRadialPattern::getColor a little bit to solve
>>>>>>>>>>> this. It is still a little bit different from the old one, in my
>>>>>>>>>>> opinion a little bit better, but that's just a flavour, and in
>>>>>>>>>>> other cases it could be a little bit more worse. So if You agree,
>>>>>>>>>>> I can send
>>>>>>>>>>> a complete new patch.
>>>>>>>>>>>
>>>>>>>>>>> BTW, as You probably see, Andrea attached his PDF to the closed
>>>>>>>>>>> bug 32349. I saw already yesterday, that also the new rendering
>>>>>>>>>>> with the latest patch is quite better than the old rendering,
>>>>>>>>>>> but it's still not shown what Acrobat reader shows. I'll have an
>>>>>>>>>>> additional look in it, but I fear that this will be again a
>>>>>>>>>>> bigger job (the PDF has 128 radial shadings, and only some of
>>>>>>>>>>> them are still buggy!). So (if not solvable in time) I would
>>>>>>>>>>> prefer to close this thread first, and then reopen the bug or
>>>>>>>>>>> create a new one.
>>>>>>>>>>>
>>>>>>>>>>> Do You agree, or do You have other ideas?
>>>>>>>>>>>
>>>>>>>>>>> Thomas
>>>>>>>>>>>
>>>>>>>>>>> FYI, here the changes:
>>>>>>>>>>>
>>>>>>>>>>> GBool SplashRadialPattern::getColor(int x, int y, SplashColorPtr
>>>>>>>>>>> c) {
>>>>>>>>>>>
>>>>>>>>>>> double xc, yc;
>>>>>>>>>>> int xs, ys;
>>>>>>>>>>> Guchar *bitmapAlpha;
>>>>>>>>>>>
>>>>>>>>>>> bitmapAlpha = bitmap->getAlphaPtr();
>>>>>>>>>>> ictm.transform(x, y,&xc,&yc);
>>>>>>>>>>> xs = splashRound(xc);
>>>>>>>>>>> ys = splashRound(yc);
>>>>>>>>>>> // Because of rounding problems, coordinates could be
>>>>>>>>>>> // outside the bitmap. Reset them on the outer bound now
>>>>>>>>>>> // and let it up to the alpha channel if they are shown:
>>>>>>>>>>> if (xs< 0) xs = 0;
>>>>>>>>>>> if (xs>= bitmap->getWidth()) xs = bitmap->getWidth() - 1;
>>>>>>>>>>> if (ys< 0) ys = 0;
>>>>>>>>>>> if (ys>= bitmap->getHeight()) ys = bitmap->getHeight() - 1;
>>>>>>>>>>> if (bitmapAlpha[ys * bitmap->getWidth() + xs])
>>>>>>>>>>>
>>>>>>>>>>> bitmap->getPixel(xs, ys, c);
>>>>>>>>>>>
>>>>>>>>>>> else
>>>>>>>>>>>
>>>>>>>>>>> return gFalse;
>>>>>>>>>>>
>>>>>>>>>>> return gTrue;
>>>>>>>>>>>
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Am 29.12.2010 23:28, schrieb Albert Astals Cid:
>>>>>>>>>>>> First page, left of the "title". A few white pixels in there.
>>>>>>>>>>>>
>>>>>>>>>>>> Albert
>>>>>>>>>>>>
>>>>>>>>>>>> A Dimecres, 29 de desembre de 2010, Thomas Freitag va escriure:
>>>>>>>>>>>>> Am 29.12.2010 18:53, schrieb Andrea Canciani:
>>>>>>>>>>>>>> On Wed, Dec 29, 2010 at 4:48 PM, Thomas Freitag
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> <Thomas.Freitag at kabelmail.de> wrote:
>>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>> I made a mistake when solving the problem with
>>>>>>>>>>>>>>> altona_visual_1v2a_x3.pdf. I find now a better way to solve
>>>>>>>>>>>>>>> it, which
>>>>>>>>>>>>>>> also gives a better look of the printer paper back again.
>>>>>>>>>>>>>> I'd like to point yo to another pdf whose rendering regresses
>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>> patch: https://bugs.freedesktop.org/attachment.cgi?id=41506
>>>>>>>>>>>>> Albert, can You please just change two lines in the former
>>>>>>>>>>>>> patch? 1. In SplashOutputDev.cc in the constructor of
>>>>>>>>>>>>> SplashRadialPattern, replace
>>>>>>>>>>>>> + bitmap = new SplashBitmap(splashRound(width) + 1,
>>>>>>>>>>>>> splashRound(height)
>>>>>>>>>>>>> + 1, colorMode != splashModeMono1, colorMode, gTrue);
>>>>>>>>>>>>> through
>>>>>>>>>>>>> + bitmap = new SplashBitmap(splashRound(width) + 2,
>>>>>>>>>>>>> splashRound(height) + 2, colorMode != splashModeMono1,
>>>>>>>>>>>>> colorMode, gTrue);
>>>>>>>>>>>>> 2. In Splash.cc in the painting routine radialShadedFill, where
>>>>>>>>>>>>> the smaller extend circle is painted, replace
>>>>>>>>>>>>> + drawPartEllipseLine(&pipe, 2* yo - curY, xMin, xMax);
>>>>>>>>>>>>> through
>>>>>>>>>>>>> + drawPartEllipseLine(&pipe, curY, xMin, xMax);
>>>>>>>>>>>>> (curY is alfready recalculated two line before!)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Or just reapply the attached patch.
>>>>>>>>>>>>> This solves the rendering regressions mailed by Andrea.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>
>>>>>>>>>>>>>> In the last row, half of the inner circle is transparent with
>>>>>>>>>>>>>> poppler/master+radialsh.patch.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andrea
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> PS: Sorry for removing most of the thread from this message,
>>>>>>>>>>>>>> but gmail
>>>>>>>>>>>>>> squashed it to just one level.
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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 HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20110109/d2fb00db/attachment.html>
More information about the poppler
mailing list