A Dijous, 27 de gener de 2011, Andrea Canciani va escriure: > On Thu, Jan 27, 2011 at 10:45 AM, Thomas Freitag > > <[email protected]> wrote: > > 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 > > compromises): > > 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 > >> shadings. > > > > Regarding that time schedule I I suggest once again the following: > > a) we move the switch on of antialiasing from univariateShadedFill back > > to axialShadedFill. > > Although I admit I don't like axial shadings being left broken just because > nobody had previously noticed, I guess this is ok. This will still improve > radial gradients and we can enable antialiasing again when the glitches > are fixed. > > > 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 > > regtest) > > The cache is not exact, there will be differences. The sampling > only guarantees that there will be at least enough samples to have a > correct rasterization. An exact (and efficient) caching is only possible > for piecewise linear color functions (and I hope to get it right soonish, > the main obstacle right > now is that I have to be careful and clip everything to the domain and > range). > > > 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 > > proposal. > > Yes, I used git to create the patches. > > > 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. > > IIRC you mentioned that antialiasing is disabled for axial gradients when > they have a bbox (although I could only see that usesShape is disabled). > Would this be sufficient for radial gradients? (It seems to be sufficient > to work around the problem in altona, but I don't know if there are other > difficult documents) > > > Another (German?) dictum says: The whole life is a compromise :-) > > And this compromise doesn't even look that bad, radial gradients > improve and other things don't regress ;)
So what should i regtest, the last radialsh.patch sent by Thomas (yesterday at 09:45:56 Irish Time) or you want to send me a new patchset? Albert > > Andrea > > > Thomas > > > >> Anyone disagrees? > >> > >> Albert > >> > >>> Albert > >> > >> _______________________________________________ > >> 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
