Re: [svg2] radialGradient @fr constraints

Jasper van de Gronde:
...
>Olaf:
>> My understanding is, that there are two areas for spreadMethod,
>> outside the circle determined by cx, cy,r and inside the
>> circle determined by fx, fy, fr, respectively if the first stop offset
>> is not 0.

>Yes and no. The spreadMethod can best be interpreted as what to do for
>values of t outside the interval [0,1]. So if the zero-radius point (or
>focus) is inside the circle, then you indeed have the areas you
>specified. In other cases, there are two cones/wedges that get filled.

As already cited from the draft - and similar text is available as well
in SVG 1.1 - spreadMethod is intended to fill the complete area the
gradient is applied to, it does not talk about cones/wedges.
One simply has to fill the target area somehow with the information
given in the gradient definition.

>> If one allows to set the f-circle outside the r-circle, one has
>> to define the order, the gradient has to be realised, including
>> the spreadMethod. 
>
>The order is effectively given already (in terms of the stop offset/t),
>and all specifications that allow this agree on the same method (which I
>have also used). Basically larger values of t are drawn on top of
>smaller values. Essentially you're looking down on a 3D cone (with t
>being the 3rd dimension).

No, currently SVG does not indicate at all, how to get the effect, it
defines only how to interprete the stops to get an unambiguous effect.
This results only in the fact, that you know, which color is finally at
which position (interpolation may depend on other attributes of course).
It is 2D graphics, therefore no part of the gradient is on top of another.
This is possible, because there cannot be a self-intersection up to now.
For the stop of a radial gradient this means only, that an offset of 0 is
at (fx,fy) and 1 is at the r-circle, the others interpolate between.

With the option to have the f-circle not always inside the r-circle you
suddenly have the situation, that there can be 2 (or more?) color values
for one point and one needs to define, which applies and how or if
stop-opacity applies to self-intersecting areas. The offset values
do not imply all this - currently it is only possible to have two successive 
offsets with the same value, and the behaviour is defined. 
If the f-circle can be outside the c-circle, for one point there can be
two arbitrary offsets defining different colors and opacities for the 
same point(s) and currently there is no definition, which one to choose - 
and the range of offset values do not imply this. The offsets provide
only information about positions, not about priorities, which offset is
on top if two different apply for the same position. 
If user-agents have already a defined behaviour in other formats 
for intersecting gradients, which colour to choose, indeed it could be a 
good idea to use this, but currently it is not mentioned as it is not
mentioned, that f can be outside r at all - or at least what this means,
I think, currently the correction rule applies, but even this is incomplete
for fr not equal 0. 


>The appearance of the gradient is COMPLETELY determined by specifying a
>starting (t=0) circle, an ending (t=1) circle and a spread method (or
>two if you want to be able to have a different one for either end), in
>combination with the actual colour gradient of course. You're right that
>there are lots of options, but this is simply a consequence of this
>definition, it does not complicate either the specification or the
>implementation.

If we follow this idea to implicate an order, then simply the 
spreadMethod for the t>1in your notation will cover all fragments,
that will result from f outside r, because it defines everything beyond
r and is on top.

>> * which order is more useful?
>> * should the author have the choice of the order or should it be
>> possible to switch inside and outside or the meaning of r and f
>> (fr >= r)?
>
>Unless I'm completely missing your point, there are only two choices:
>larger t over smaller t or smaller t over larger t. Given that they are
>equivalent (if you want the other, simply swap the starting and ending
>circle) and that larger t over smaller t is what has been used up to
>now, I'd recommend simply going with larger t over smaller t.

To keep the example simple assume all cx, cy, fx, fy to be 0.
assume r=100, fr=200,
color for offset 0 is red, for 1 is blue.
We use spreadMethod pad.

If we assume your order to get the gradient, first on will set
everything to red what is below fr=200.
Then one does the gradient to r=100 with some interpolation.
Then one has to set the blue pad for everything with r>100.

Result: 
red from 0 to 100, blue from 100 to the end of the filled area.
- somehow useful? Maybe not ...

If an author can switch the order, it should be possible to
see the interpolated gradient between 100 and 200:
red from 0 to 100, blue to red from 100 to 200, blue beyond 200
- somehow useful? Maybe for the gradient, maybe not for
the spreadMethod areas.

If the f-circle can be outside the r-circle, the meaning becomes
almost symmetrical, therefore an order for overlaps is not obvious, 
if not explictly defined.

And it is not defined as well, when the spreadMethod has to
be applied, before the gradient from f to r is realised or after,
or one before, one after, as your assumptions seems to imply.

To be able to switch the order in case of overlaps can be useful
for authors.

>> * maybe interesting as well to set (approximately) 
>> r=fr, cx=fx, cy=fy and to see what will happen with spreadMethod 
>> in real implementations ;o)
>
>Ah, yes... That is definitely an interesting one. Technically, if they
>are exactly equal, nothing should be drawn (all infinitely thin circles
>are on top of each other). 

The spreadMethod has to be drawn, one for inside, one for outside.
Outside the rule of weighted average seems to be applicable,
inside as well?
If spreadMethod is not pad, you get an infinite number of repetitions
inside and outside as well.

If it is only approximately the same, you may get the chaotic
behaviour again, generating some noise, depending
on the accuracy level of the viewer - in a few directions the
number of repetitions of spreadMethod may get infinite as well.
I suggested already to explictly mention an accuracy level
for points that are assumed to be on the circle for the
weighted average rule. This may result in the same
effect in different viewers, no random noise.


>It's essentially a worse version of the 
>problem I showed in my post, and could be dealt with in much the same
>way (specifically, the same measures suggested there would help solve
>this problem as well). In a way the current SVG spec deals with it by
>again enforcing that the focus should be contained within the circle, so
>that instead of having two points on top of each other, conceptually we
>have a point and an infinitely small circle around it.

Well, r and fr can have both finite size, for example both 100, or
in the approximate case, one is 'close to' 100 and cx, cy, fx, fy are moving
around 0 or another arbitrary point for example. 


Will there be more fun with this with the new gradient meshes?
Paths can be self-interesection as well, causing even more
mathematical interesting situations, one has to take into account.
(Currently the fragment about gradient meshes is far too incomplete
to be understandable, how it will work).



Olaf

Received on Tuesday, 4 September 2012 14:58:01 UTC