<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Am 15.01.2011 17:01, schrieb Thomas Freitag:
<blockquote cite="mid:4D31C4F4.3010809@kabelmail.de" type="cite">Am
13.01.2011 21:55, schrieb Albert Astals Cid:
<br>
<blockquote type="cite">A Dimecres, 12 de gener de 2011, Thomas
Freitag va escriure:
<br>
<blockquote type="cite">Am 09.01.2011 23:48, schrieb Albert
Astals Cid:
<br>
<blockquote type="cite">A Diumenge, 9 de gener de 2011, Thomas
Freitag va escriure:
<br>
<blockquote type="cite">Am 08.01.2011 00:56, schrieb Albert
Astals Cid:
<br>
<blockquote type="cite">A Dilluns, 3 de gener de 2011,
Thomas Freitag va escriure:
<br>
<blockquote type="cite">Am 03.01.2011 00:28, schrieb
Albert Astals Cid:
<br>
<blockquote type="cite">A Diumenge, 2 de gener de
2011, Thomas Freitag va escriure:
<br>
<blockquote type="cite">Am 01.01.2011 22:34, schrieb
Albert Astals Cid:
<br>
<blockquote type="cite">A Dissabte, 1 de gener de
2011, Thomas Freitag va escriure:
<br>
<blockquote type="cite">Please regtest this new
patch. What I've done in the meantime:
<br>
<br>
a) speed up the implemenation but have enough
quality left.
<br>
b) implement the shading extend in a correct
way, test it against
<br>
the samples from the PDF spec (appendix L)
<br>
c) test it against all samples from Andrea,
including bug 32349&
<br>
30887. d) test it against ducks&
roses and all the PDF You
<br>
send me because of regressions with former
patches.
<br>
<br>
So I'm think I'm quite near of finishing the
implementation, just
<br>
waiting for the result of Your regtest.
<br>
</blockquote>
There are a few empty pixels in the border of
<br>
<a class="moz-txt-link-freetext" href="http://bugsfiles.kde.org/attachment.cgi?id=20680">http://bugsfiles.kde.org/attachment.cgi?id=20680</a>
<br>
</blockquote>
Sorry, I made such a lot changes in the last three
days, that I
<br>
forgot to remove a test case where I wanted to see
where normal
<br>
shading stops and extending shading starts, so the
last circle of
<br>
normal shading was no more painted :-(
<br>
<br>
Please try the new patch.
<br>
</blockquote>
There is a regression on page 25 of
<br>
<a class="moz-txt-link-freetext" href="http://download.tuxfamily.org/magnum/doc/magnum04.pdf">http://download.tuxfamily.org/magnum/doc/magnum04.pdf</a>
<br>
<br>
See attached files.
<br>
</blockquote>
This was not really a bug in the new feature "radial
shading": when I
<br>
introduced the dynamic pattern in axial shading, and
the ability to
<br>
return gFalse in getColor() if nothing should be
paint, I forgot to
<br>
increase some pipe pointers in pipeRun, i.e. if
softmask is used the
<br>
softmask pointers must be increased, too.
<br>
<br>
Please try the new patch.
<br>
<br>
BTW, Albert: I start working again, and because this
is almost a
<br>
private pleasure, I can probably look only on weekend
into new
<br>
regressions. And because I think we are really quite
near, could You
<br>
please run the regression test over all PDF and send
me them all or
<br>
links to it instead stopping the test if You first
regression? Then I
<br>
can look at all regressions next weekend...
<br>
</blockquote>
</blockquote>
It seems as if I was a little bit to optimistic:
<br>
<blockquote type="cite">The image generated by the new
implementation is still considerably
<br>
"blockier" than the generated by the old one in page 25
of that pdf.
<br>
</blockquote>
Solved, and the new routines are faster!
<br>
<br>
<blockquote type="cite">There is a regression in page 8 of
<br>
<a class="moz-txt-link-freetext" href="http://launchpadlibrarian.net/17355619/2008SPYSupplement.pdf">http://launchpadlibrarian.net/17355619/2008SPYSupplement.pdf</a>
<br>
</blockquote>
Solved, new and old routines need nearly the same time
<br>
<br>
<blockquote type="cite">There is a regression on the top
left bubble of
<br>
<a class="moz-txt-link-freetext" href="https://bugs.freedesktop.org/attachment.cgi?id=32823">https://bugs.freedesktop.org/attachment.cgi?id=32823</a>
<br>
</blockquote>
Solved, new and old routines need nearly the same time.
<br>
<br>
<blockquote type="cite">There is a regression in the alfa
romeo logo of one of the files you
<br>
sent for
<a class="moz-txt-link-freetext" href="https://bugs.freedesktop.org/show_bug.cgi?id=27482">https://bugs.freedesktop.org/show_bug.cgi?id=27482</a> (if
you
<br>
don't have it anymore ask and i'll send it to you)
<br>
</blockquote>
Solved, new and old routines need nearly the same time.
<br>
<br>
<blockquote type="cite">The pdf at
<a class="moz-txt-link-freetext" href="https://bugs.freedesktop.org/attachment.cgi?id=40344">https://bugs.freedesktop.org/attachment.cgi?id=40344</a>
turned
<br>
to grayscale
<br>
</blockquote>
Solved, new and old routines need nearly the same time.
<br>
<br>
<blockquote type="cite"><a class="moz-txt-link-freetext" href="https://bugs.freedesktop.org/attachment.cgi?id=41060">https://bugs.freedesktop.org/attachment.cgi?id=41060</a>
looks really
<br>
blocky too with the new patch
<br>
</blockquote>
Better, but still a little bit blockier. Seems to be the
Bresenham
<br>
routines.
<br>
<br>
<blockquote type="cite"><a class="moz-txt-link-freetext" href="https://bugs.freedesktop.org/attachment.cgi?id=6858">https://bugs.freedesktop.org/attachment.cgi?id=6858</a>
is considerably
<br>
slower with the new patch than with the old code (takes
more than the
<br>
six times the old code and then stopped trying so no
sure if the
<br>
rendering is
<br>
better/worse/the same)
<br>
</blockquote>
I've optimized it, but I still need a little bit less than
six times
<br>
than with the old routines. Reason for this (a PDF with
round about 600
<br>
radial shadings!) are some radial shadings with a radius
of more than
<br>
10.000.00 pts and then pick a partial square with 256 pts.
With
<br>
Bresenham I have to calculate als the 10.000.000 circle
points before I
<br>
can intersect :-(
<br>
<br>
<blockquote type="cite">There is another circle that got
very blocky, i'll send you the file.
<br>
</blockquote>
No solution 'til now. It's hard to look into it, it need
more than 15
<br>
minutes on my not so slow laptop for rendering until it
reaches the
<br>
first radial shading, so I give up for today.
<br>
<br>
Seems as if I need to spend at least one additional
weekend for it. I
<br>
have an idea to combine old drawing circles with only 66
points instead
<br>
of using Bresenham algorithm to get it faster, but I've to
make some
<br>
more tests on this.
<br>
<br>
If You think I can upload a new patch with the actual
resuts, just to
<br>
look for new / other regressions. Otherwise we can of
course wait after
<br>
I finish it.
<br>
</blockquote>
I think i prefer to wait until you have a patch that fixes
all the known
<br>
regressions until doing another regression test run.
<br>
<br>
Thanks :-)
<br>
<br>
Albert
<br>
</blockquote>
I think, I'm through. Here the new optimized patch. Now I'm
mostly
<br>
faster then the old implementation, only when the corrected
<br>
implementation of larger extension circle is needed, I need
sometimes
<br>
more time. See for example the european map You sent me in
private,
<br>
where the ships were very blocky: with the new implementation
this is
<br>
solved and the square around the ships are away (which is
correct, they
<br>
should not be there!). Even in the corrected implementation of
larger
<br>
extension circles I made a lot of optimization steps, see i.e.
<br>
<a class="moz-txt-link-freetext" href="https://bugs.freedesktop.org/attachment.cgi?id=41506">https://bugs.freedesktop.org/attachment.cgi?id=41506</a> from
Andrea, which
<br>
is now rendered correctly and in time. I'm also able to render
now the
<br>
PDFs in <a class="moz-txt-link-freetext" href="http://people.freedesktop.org/~ranma42/cairo/radial/">http://people.freedesktop.org/~ranma42/cairo/radial/</a>
from
<br>
Andrea, I think, I found a good compromise between speed and
quality there.
<br>
Only <a class="moz-txt-link-freetext" href="https://bugs.freedesktop.org/attachment.cgi?id=41060">https://bugs.freedesktop.org/attachment.cgi?id=41060</a>
still looks a
<br>
little bit uglier (blockier) than with the old routines, but
because
<br>
this is more or less an artificial radial shading, I would
accept this
<br>
case. What are You thinking about that?
<br>
Last but not least, even if You'll find new regressions with
the new
<br>
patch, I want really to thank Andrea Canciani for his samples.
Not only
<br>
that it's easier testing complete new code with PDF files,
which only
<br>
contain radial shadings and nothing else, they also gives me a
deeper
<br>
understanding how radial shading is specified in comparision
what I
<br>
understood reading the Adobe PDF spec.
<br>
<br>
Please test the new patch,
<br>
</blockquote>
It dies with a "Bogus memory allocation size" in
<br>
<a class="moz-txt-link-freetext" href="https://bugs.kde.org/attachment.cgi?id=27458">https://bugs.kde.org/attachment.cgi?id=27458</a>
<br>
</blockquote>
The memory problems were coming still from the wrong calculation
of shading extension which I took from Gfx.cc and tried to
correct, but it still leaded to huge circles. Andrea gave me a
hint of a correct calculation of radial shading extension in
cairo, and I adapated that code piece now successfully to Splash.
It seems, as if with this the memory problems are now gone, at
least I could render every PDF You sent me in the past, and I
couldn't find any regressions in the rendering results.
<br>
<br>
Please test this patch, sorry if I boring You sending one patch
after another,
<br>
Thomas
<br>
</blockquote>
Please don't wonder that I upload once again a patch for radial
shading. Before You try this one, please finish first regtesting the
patch from yesterday.<br>
When I worked on implementing radial shading, I already thought that
it should be possible directly get the color from the radial shading
object having just the x,y-position, without having any other tools.
But i wasn't sure, so I wanted to finish the implementation with the
bitmap as tool first.<br>
Today early morning I started to "undef" the bitmap tools and
implementing the direct way. And as You see now, I succeed, and it
dramatically speed up rendering and quality in almost every PDF I
tested. Only when there is a huge bitmap in which a huge radial
shading should be placed, I need more time. One example for this
poorer speed is once again the ducks & roses: Even if You don't
see that, the most shadings there are done in a bitmap of 16384 pts
and then downscaled. So with this special PDF (and it was the only
one where this happens in my tests), rendering needs now
approximately the double amount of time. In every other case I was
at least as fast as before, having a better quality (i.e. the
magnum.pdf, the small white circles are gone now and we have a
smooth shading, really comparable what the acrobat does). And last
but not least: I render Andrea's PDF (the non reduced one, where
acrobat gives up), in round about 25 seconds in high quality.<br>
Even with this enhancements, I kindly ask You to finish regtesting
the former patch and let the "undef"ed code from this patch in,
after it runs through Your regression test, too. Reason for this
request is, that in case of futur regressions in radial shading I
can easily insert it again and can determine where the colors are
differnt with these two methods.<br>
<br>
Thanks a lot in advance,<br>
Thomas<br>
<blockquote cite="mid:4D31C4F4.3010809@kabelmail.de" type="cite">
<br>
<blockquote type="cite">Albert
<br>
<br>
<blockquote type="cite">Thomas
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">Thomas
<br>
</blockquote>
_______________________________________________
<br>
poppler mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:poppler@lists.freedesktop.org">poppler@lists.freedesktop.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/poppler">http://lists.freedesktop.org/mailman/listinfo/poppler</a>
<br>
<br>
.
<br>
</blockquote>
</blockquote>
_______________________________________________
<br>
poppler mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:poppler@lists.freedesktop.org">poppler@lists.freedesktop.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/poppler">http://lists.freedesktop.org/mailman/listinfo/poppler</a>
<br>
<br>
.
<br>
<br>
</blockquote>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
poppler mailing list
<a class="moz-txt-link-abbreviated" href="mailto:poppler@lists.freedesktop.org">poppler@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/poppler">http://lists.freedesktop.org/mailman/listinfo/poppler</a>
</pre>
</blockquote>
<br>
</body>
</html>