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

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

.
.


_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler


_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler


_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler

_______________________________________________
poppler mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/poppler

Reply via email to