You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thomas E Deweese <th...@kodak.com> on 2001/07/10 19:38:15 UTC
Gradients and antialiasing
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: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Gradients and antialiasing
Posted by Thierry Kormann <tk...@ilog.fr>.
On Wednesday 11 July 2001 15:14, Thomas E Deweese wrote:
> >>>>> "TK" == Thierry Kormann <tk...@ilog.fr> writes:
>
> TK> On Tuesday 10 July 2001 19:38, Thomas E Deweese wrote: Hi,
>
> >> 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.
>
> TK> That makes sence.
>
> TK> I agree that the default should by antialisingOff.
>
> Well, actually I wasn't proposing that :)
Well, your proposal sounds good - this is what I was thinking when writing
the email :)
> Please take a look at samples/tests/radialGradient2.svg with and
> without the anti-aliasing code before deciding anti-aliasing should be
> off (you need to play with the USE_ANTI_ALIAS static in
> RadialGradientPaintContext).
I will. May be we could start thinking of the antialising clipping you have
done before and was so nice as now the rendering hints work.
> Should I key off shape-rendering or color-rendering? Neither is a
> great fit but I think of shape-rendering as just the edges of
> filled/stroked objects, color-rendering starts getting to how precise
> the rendering engine should be about color handling. I guess for now
> I'll key off shape-rendering since that is implemented.
Well, I will say KEY_COLOR_RENDERING or KEY_RENDERING or both. BTW I set
multiple J2D rendering hints per SVG hint (because there is not a one one
matching and because of text - eg. text can be rendered using shape so g2d
will consider shape rendering hints instead of text ones).
> Just an FYI, the bridge was killing the previous stop, so it never
> made it to the gradient code (which does properly handle the case).
> My small fix in the abstract gradient bridge class fixed this. My new
> test tests this case as well.
Yes, that was not really clear in the previous specs or at least the one I
used while implementing the gradient bridges. Now I have seen that an example
has been added and the behavior you and christophe described is the correct
one. good catch.
Thierry.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Gradients and antialiasing
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "TK" == Thierry Kormann <tk...@ilog.fr> writes:
TK> On Tuesday 10 July 2001 19:38, Thomas E Deweese wrote: Hi,
>> 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.
TK> That makes sence.
TK> I agree that the default should by antialisingOff.
Well, actually I wasn't proposing that :)
Please take a look at samples/tests/radialGradient2.svg with and
without the anti-aliasing code before deciding anti-aliasing should be
off (you need to play with the USE_ANTI_ALIAS static in
RadialGradientPaintContext).
>> My question is for Thierry or Vincent. Is the optmizeXXX stuff
>> working yet? If so how are the hints mapped?
TK> Yes. shape-rendering, text-rendering and image-rendering
TK> properties are working. You have some examples that illustrate the
TK> mapping between J2D rendering hints and SVG rendering hints in the
TK> sample/tests directory.
Good!
Should I key off shape-rendering or color-rendering? Neither is a
great fit but I think of shape-rendering as just the edges of
filled/stroked objects, color-rendering starts getting to how precise
the rendering engine should be about color handling. I guess for now
I'll key off shape-rendering since that is implemented.
>> 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:
TK> [...] So I already do lots of things in the gradient bridges. I
TK> could do that one if you think it's my job (I think it
TK> is). Anyway, the previous implementation of the gradients handles
TK> the case of 2 offsets with the same value and do what the spec
TK> says, so I just ignore this one in the bridge.
Just an FYI, the bridge was killing the previous stop, so it never
made it to the gradient code (which does properly handle the case).
My small fix in the abstract gradient bridge class fixed this. My new
test tests this case as well.
>> If you agree with my thinking then I will check in an updated
>> version of the gradient bridge that does this.
TK> I do (a bit late :)
Sorry, didn't mean to jump the gun on the commit, I assumed
Christophe had talked with you. :)
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Gradients and antialiasing
Posted by Thierry Kormann <tk...@ilog.fr>.
On Tuesday 10 July 2001 19:38, Thomas E Deweese wrote:
Hi,
> 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.
That makes sence. I agree that the default should by antialisingOff.
> My question is for Thierry or Vincent. Is the optmizeXXX stuff
> working yet? If so how are the hints mapped?
Yes. shape-rendering, text-rendering and image-rendering properties are
working. You have some examples that illustrate the mapping between J2D
rendering hints and SVG rendering hints in the sample/tests directory.
> 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:
This is something that could be easily handled by the bridge. The bridge
already does much more work for gradients. The SVG spec mentions what to do
is the radius of a radial gradient is 0, if an offset is greater than 1 or
lower than 0...
So I already do lots of things in the gradient bridges. I could do that one
if you think it's my job (I think it is). Anyway, the previous implementation
of the gradients handles the case of 2 offsets with the same value and do
what the spec says, so I just ignore this one in the bridge.
Finally, it's up to you. If you ignore this case, I can handle it in the
bridge.
> If you agree with my thinking then I will check in an updated
> version of the gradient bridge that does this.
I do (a bit late :)
Regards,
Thierry.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Gradients and antialiasing
Posted by Christophe Jolif <cj...@ilog.fr>.
Thomas E Deweese wrote:
> 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.
I agree it is the right behavior that you just described. What I found
strange, is that I tought I corrected this problem several months ago in
the MultipleGradientPaintContext code! And that theorically, it should
work . I don't understand how all of this happened, but anyway, you can
correct it of course!
--
Christophe
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org