[poppler] Radial shading in poppler

[Thomas Freitag]

Hi,

It's once again me, this time without a patch :-). I just want to 
discuss some open issues that come into my mind after sleeping one night 
over it, and this don't really depends completely on radial shading in 
Splash, therefore I open a new thread:

After digging really deep into radial shadings the last four weeks there 
are still a few open issues left:

I. Gfx::doRadialShFill
There were three different problems /  bugs which causes me to spend 
that enormous time implementing radial shading in Splash (probably 
wouldn't have done it, if I could estimate that before :-) ):
a) Rendering artefacts because of overlapping circle clipping pathes in
http://www.acquerra.com.au/poppler/img_0.pdf
b) wrong calculation of extension range causing rendering regressions in
https://bugs.freedesktop.org/attachment.cgi?id=41506
c) wrong implementation of drawing larger extension circles causing 
rendering regressions in the same PDF
These three problems cause rendering regression in each OutputDev which 
hasn't implented radialShadedFill by its own or if in case it has 
implemented it, it returns gFalse (this fits to CairoOutputDev, which 
uses its implementation just to setup some datastructure but let the 
rendering done by Gfx::doRadialShFill).
I myself encounter three main output devices:
1. PSOutputDev implements radialShadedFill and therefore does not have 
the problems ahead (of course could have some other problems with it, 
but that's then a problem of its own implementation)
2. SplashOutputDev implements radialShadedFill now by its own and will 
not have these problems anymore after one of my patches will be committed.
3. CairoOutputDev will still have these problems.
So have a quick look at CairoOutputDev. In my opinion there are two 
possible solutions for solving that:
a) CairoOutputDev implements radialShadedFill by itself. I'm not deep 
enough in cairo to determine if this could be a possible way, perhaps 
with some hints from me and / or Andrea.
But if this would be too heavy and / or the rendering regressions with 
the first PDF (see here the wine glass) would be acceptable, I could 
suggest another way:
b) I correct the bugs two and three in Gfx::doRadialShFill, the first 
one is unfortunately not correctable in Gfx. The second bug is simply 
correctable by a code fragment that already comes from cairo, which I 
already use adapted successfully in my both patches for splash, for the 
third bug I could adapt the different way of drawing larger extension 
circles of my patch from saturday (therefore, once again, Albert, this 
is an additional reason for regtest this older patch, too).

II. Speed an quality using radial shading in Splash:
I uploaded last weekend two patches for it with two different 
implementation methods. The patch from sunday has definitely a better 
quality but in a very few cases sucks in rendering speed than the patch 
from saturday, which on the other hand has a poorer quality. Perhaps we 
can find somehow a threshold value on which we can decide, wether method 
should be used. This could be an additional reason to regtest both 
patches, but commit only the patch from sunday with the "undef"ed code 
so that it would be easy to implement this new behaviour later on.

I need not necessarily do the work of I or II, but if the community 
means that I should do that, I suggest we open a new bug with this two 
PDF. I worked nearly every free minute on solving the problems in splash 
the last four weeks, and the patch is still not committed and there 
could of course be some work left (hopefully none or only a few), so I 
want to take time out, and therefore a bug report is reasonable.

Thomas