Can we fix arc interpolation?

[LeaVerou]

(Originally posted in w3c/csswg-drafts#10195)

Currently paths are naively interpolated by matching up segments and points and interpolating them as numbers.
This is defined in the Paths section:

For animation, two d property values can only be interpolated smoothly when the path data strings contain have the same structure, (i.e. exactly the same number and types of path data commands which are in the same order). If an animation is specified and the lists of path data commands do not have the same structure, then the values must be interpolated using the discrete animation type.

If the list of path data commands have the same structure, then each parameter to each path data command must be interpolated separately as real numbers. Flags and booleans must be interpolated as fractions between zero and one, with any non-zero value considered to be a value of one/true.

So basically, control points are animated separately, and flags (of which the arc command has two!) just flip halfway.
This works decently for most path types, but as you can see in this demo this produces terrible, terrible results for arcs.

Here is another example: a dynamic pie chart using CSS transitions on d to animate across state changes (using a 3s duration to clearly show what’s happening):

arc-wrong.mp4

Fixing this in authorland is incredibly tricky and computationally expensive. Worse yet, it’s one of those things that seem deceptively simple from the outside, but incredibly hard once you’re actually working on them.

This can be easily fixed at the source, without any author-facing changes, by simply adopting smarter interpolation rules for arc commands, which interpolate the actual features of the arc (offset, angle, radii, etc.) instead of the coordinate points and flags.

As @svgeesus pointed out in w3c/csswg-drafts#10195 (comment), the interconversion between actual arc features and SVG path syntax is well defined.

There’s the question of whether changing the default behavior here would be web compatible, but as @tabatkins points out in w3c/csswg-drafts#10195 (comment) there is practically no case where the current behavior is desirable (except demos like mine showing how bad it is 😅 ).

So I guess the questions to answer are:

1. Do we have consensus that the new behavior is better?
2. (Assuming yes to 1 above) Do we have consensus that it’s web compatible to change the default behavior, or do we need an author facing opt-in?
3. (Assuming yes to 1 above) How will the specifics work? @tabatkins raised some questions around interpolating just the flags (though perhaps the math @svgeesus linked to make this a non-issue, I have not checked).

If we have consensus on these, I'd be happy to do some work towards fixing this.

[shepazu]

This seems pretty obvious to me. I can see no benefit to keeping the old behavior, and seriously doubt any existing content is using the old behavior. In any case, we should favor the utility for authors over mindless adherence to "backwards compatibility".

There's historically been a lot of reluctance among browser vendors to change or improve their SVG implementations, but if that inertia can be overcome, I think this would be an excellent change (modulo the details to be worked out, of course).

This is one of those cases where a small amount of work by standards and implementers could save authors and tools a disproportionate amount of work and frustration.

[LeaVerou]

There's historically been a lot of reluctance among browser vendors to change or improve their SVG implementations, but if that inertia can be overcome, I think this would be an excellent change (modulo the details to be worked out, of course).

I’m (cautiously) optimistic because this doesn’t require any actual syntax changes, and affects CSS too (clip-path etc).

[svgeesus]

1. Yes the newer way is better. The old way is basically the inflexible application of existing rules in a content-unaware way, and gives terrible results.
2. Because it is so terrible, no-one uses it more than once (and their first attempt does not get used, except as an example of how bad things are)
3. The conversion from end-point to center parameterization gets rid of the flags; it is the center parameterization that gets animated, with useful parameters like Δθ

[Doktorchen]

The SVG2 draft has still no version numbering - therefore there must be no backwards incompatible addition or changes.

My suggestion: Add version numbering and new commands for another type of arc for alternative usage/applications.
There were already new commands suggested or worked out for SVG2.
Because there is still no recommendation for SVG2, it is still time enough to add all required new features an new meaningful suggestions to the SVG2 draft to get finally something useful/usable for authors beyond SVG1.1 and SVG tiny 1.2.