Hi all,
I've got a new version of the gradient code that does true
anti-aliasing. I'm going to commit it shortly (with AntiAlias off),
however this note is for me to ask some questions and get some feed
back.
The new Anti-alias implementation is about 25% slower, which is
actually _very_ good considering the extra work being done, but I'm
not sure it's good enough for use all the time. Especially since while
for some gradients the new version is strikingly better, in many
common cases it generally makes little visible difference, I didn't
touch the current fastest and most common case (focal pt == center pt,
simple-lookup).
Since this is your 100% typical speed vs. quality tradeoff it seems
pretty clear that for color-rendering (perhaps shape rendering?) set
to optimizeSpeed gradient anti-aliasing should be off for
optimizeQuality it should be on. This of course leaves the question
of what to do in the default case.
So the feedback I'm looking for is would people want to see the
default be high quality slightly slower rendering of gradients or
lower quality (for some cases) and generally faster rendering of
gradients, the radialGradient test and a new radialGradient2 test are
good for showing where it does and doesn't make a difference.
I could also make the default behavior a bit more complex, since
for the simple-lookup[*] case you don't generally need the
anti-aliasing except for spreadMethod=repeat. So I could have the
default be use non-anti-alias for simple gradients, and use
anti-aliasing for 'complex' gradients or one's that make use of
spreadMethod repeat. I'm not fond of this sort of thing since
non-obvious changes in the source SVG can cause a change in the
rendering mechanism used (for instance adding another color to the
gradient, or changing stop locations).
[*] The simple case is where the gradient can be expressed without
loss of precision in a 4096 entry lookup table (4096 is arbitrary),
this is effected most notably by the smallest difference between two
stops in your stops list.
My question is for Thierry or Vincent. Is the optmizeXXX stuff
working yet? If so how are the hints mapped?
Finally, Thierry, as I recall there was some debate over how
gradients that use the same stop value twice should be handled, what
is implemented in Batik doesn't match my recollection of the
discussion. Right now Batik deletes the first stop at the value, I
think it should keep it and have the gradient have a discontinuity:
So the following:
<radialGradient id="rgDefaults">
<stop offset=".0" stop-color="gold" />
<stop offset=".5" stop-color="crimson" />
<stop offset=".5" stop-color="gold" />
<stop offset="1." stop-color="crimson" />
</radialGradient>
Should produce a gradient that goes from gold at zero to crimson at
_just_ before 0.5. Then at 0.5 it suddenly switches back to gold and
starts back to crimson at 1.0. So it is approx equivalent to:
<radialGradient id="rgDefaults">
<stop offset=".0" stop-color="gold" />
<stop offset=".49999999999" stop-color="crimson" />
<stop offset=".5" stop-color="gold" />
<stop offset="1." stop-color="crimson" />
</radialGradient>
If you agree with my thinking then I will check in an updated
version of the gradient bridge that does this.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
