[svgwg] Can we fix arc interpolation? (#941)

LeaVerou has just created a new issue for https://github.com/w3c/svgwg:

== Can we fix arc interpolation? ==
_(Originally posted in https://github.com/w3c/csswg-drafts/issues/10195)_

Currently paths are naively interpolated by matching up segments and points and interpolating them as numbers.
This is defined in the [Paths section](https://svgwg.org/svg2-draft/paths.html#DProperty):

> For animation, two [d](https://svgwg.org/svg2-draft/paths.html#DProperty) 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](https://drafts.csswg.org/web-animations/#animation-interpolation) using the [discrete](https://drafts.csswg.org/web-animations/#discrete-animation-type-section) animation type.
> 
> If the list of path data commands have the same structure, then each parameter to each path data command must be [interpolated](https://drafts.csswg.org/web-animations/#animation-interpolation) separately [as real numbers](https://drafts.csswg.org/web-animations/#real-number-animation-type). 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](https://svelte.dev/repl/4258ae76ca5641138402d267686e1e7e?version=4.2.12) 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):

https://github.com/w3c/csswg-drafts/assets/175836/3b88b0ce-0254-41a4-b546-fd5fb58ef4b8

Fixing this in authorland is [incredibly tricky](https://vis-society.github.io/labs/9/#step-33-fixing-the-shape-transition-using-d3transition) 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 https://github.com/w3c/csswg-drafts/issues/10195#issuecomment-2048251808, the interconversion between actual arc features and SVG path syntax is [well defined](https://www.w3.org/TR/SVG/implnote.html#ArcSyntax).

There’s the question of whether changing the default behavior here would be web compatible, but as @tabatkins points out in https://github.com/w3c/csswg-drafts/issues/10195#issuecomment-2048118498 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?
2. _(Assuming yes to 1 above)_ How will the specifics work? @tabatkins [raised some questions](https://github.com/w3c/csswg-drafts/issues/10195#issuecomment-2048118498) around interpolating just the flags (though perhaps the math @svgeesus linked to make this a non-issue, I have not checked).

Please view or discuss this issue at https://github.com/w3c/svgwg/issues/941 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 21 April 2024 19:38:28 UTC