[poppler] Followup Bug 32349 & Poppler: More shading fun ;-)
Thomas.Freitag at kabelmail.de
Thu Jan 27 01:45:56 PST 2011
Am 27.01.2011 00:44, schrieb Albert Astals Cid:
> A Dimecres, 26 de gener de 2011, Albert Astals Cid va escriure:
>> The altona file shows a vertical line that wasn't present before.
> Speaking with Andrea on IRC he blames it on a clip issue that seems to be
> present on axial shadings too.
> He says he'll try to find and fix the issue in the comming days.
> My suggestion is wait to see if he (or maybe you Thomas?) can find that
> clipping issue and then commit all the patches so we end up with no regression
> and only improvements.
I fear that this is not such a trivial issue. I think we have here at
least three different problems, I try to explain what I mean
respectively already encountered ( and what were the reasons for my
a) The way how antialiasing is implemented it splash works well if there
is a high contrast, i.e. drawing a dark object on light background. But
it gets worser if background colors and object colors are nearly the
same in brightness. That probably produces the glitches in Andrea's test
PDFs and in the altona PDF.
b) If two PDF objects are close together (without any distance) but not
on pixel boundaries, we can see sometimes two different effects: Either
we have glitches like in a) or we get white (or light) lines as everyone
probably encountered in several PDFs. Also the Acrobat Reader has
sometimes this problem, but solves it in a better way (I don't know, how).
c) If no antialiasing is used, but the objects are used in softmasks or
in transparency groups, we get also problems if the same resulting pixel
is drawn more than once. This was the effect in wine glass of ducks &
roses: because of the alpha channel implementation the pixel becomes
darker and darker the more often it is painted. That was the reason I
started implementation of radial shading in splash.
So this probably leads to not changing only a few statements but to
completely rewrite antialiasing in splash, and on the other hand any
changes will not only effect radial shading but all objects, so it will
be hard to test it. So in my company we use in such case often the
dictum: It's not a bug, it's a feature.
But let us see what Andrea will discover...
> Of course if we see that poppler 0.17 release date nears and the clip issue is
> not found-fixed yet we'll have to rethink since this patch adds better radial
Regarding that time schedule I I suggest once again the following:
a) we move the switch on of antialiasing from univariateShadedFill back
b) that means that axial shading behaves like it has done since I
implemented it last year and also with my patch here, but has the
optimize of speed from Andrea
c) that means that radial shading behaves like Albert already regtest it
with my patch, so antialiasing is not used in radial shading, but has
the optimize of speed from Andrea. Of course it then still have the
glitches in Andrea's PDF, but that's not a problem of radial shading. We
still get the improvement of that implementation.
d) the regtest should be quite easy and can be done automatically,
comparing the new results with results from Albert's last regtesting of
my patch. (This assumes that the cache that Andrea implements is an
exact cache, otherwise we could have some very small differences, which
I suppose would be acceptable but would break the automatization of the
e) if Andrea (or someone else) is able to solve the clipping problem, we
can just move back the switch on of antialiasing to univariateShadedFill
On the assumption that everyone (or at least Albert :-) ) agrees, I
attach a complete patch which should fulfil that (hopefully not missing
something) . I'm not able (or at least don't know) how to produce the
small patch segments how Andrea did it without having an own git
repository, otherwise I would have attached only the changes to Andrea's
One last point: Andrea removed my code changes from Splash::shadedFill
which allows the use of it with antialiasing switched off. Of course it
is not needed if antialiasing would be always switched on, so in my
suggestion we definitely need it again. But on the other hand it would
also be needed if someone uses SplashOutputDev without any antialiasing,
i.e. switch off antialiasing in GlobalParams. If we remove it, radial
shading (and also axial shading, but in this case it doesn't matter)
would fall back to the Gfx routines and that would produce not only
uglier but wrong results. I use this sometimes to speed up rendering,
and I suggest we should use this code changes in either case, Splash
does it also in all other routines.
Another (German?) dictum says: The whole life is a compromise :-)
> Anyone disagrees?
> poppler mailing list
> poppler at lists.freedesktop.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the poppler