Animating layout and data simultaneously

[rreusser]

One feature missing in animation is simultaneous data and layout transitions. The docs note that this is explicitly disabled. Closely related is that I'm not actually aware of a library that gets things strictly correct. Highcharts, for example, will transition both simultaneously, but in screen space, not data space. That means the data doesn't match the axis as it transitions. On top of that, to get this working correctly, instantaneous updates and finite transitions and ui interactions basically all have to be carefully coordinated to get this right.

Opening this issue to collect examples and track progress on improving the robustness.

[alexcjohnson]

One concern I have is the implicit dependence between data and layout through autorange, and how it seems like currently that could leave you in an inconsistent state:

• set up an autoranged plot
• do an animation that changes the data (and changes what the autorange results should be)
• but the autorange won't actually reevaluate, so the plot isn't really in the state implied by data and layout, until some other event causes a full redraw.

[rreusser]

Could that be controlled via an animation config flag so that the default result is consistent and you have the option to augment it with fancier behavior?

[etpinard]

cc @antoinerg

[nicolaskruchten]

I would really like to understand more about what's blocking us from currently doing this :)

@rreusser the general feeling on the team today is something like "Ricky looked at this for a while and thought it was really hard to do right so we're stuck" but I find this a bit unsatisfying... do you happen to recall anything about what the sticking points were? Were there some pathological edge cases?

I'm not sure I understand this:

Highcharts, for example, will transition both simultaneously, but in screen space, not data space. That means the data doesn't match the axis as it transitions.

[nicolaskruchten]

(I've added this to the 1.52.0 milestone not as a "we have to completely implement this in 1.52.0" but during this dev cycle I'd like us to gain clarity on what can/can't work and what would be needed)

[rreusser]

@nicolaskruchten If I recall correctly, there were a couple issues.

The first issue was simply state management since plotly generally is eager to tear things down and redraw to ensure consistency. If I recall correctly, I found it very challenging to manage the axes objects and figure out which was current or merely an outdated reference.

Regarding the specific details of animation, perhaps negligible is that the intermediate states are tweened but not strictly mathematically valid since it transitions in screen-space rather than in data-space. For example, imagine transitioning the axes and the data at the same time. The axis transition can be accomplished via a transform which would take the data with it (rather than tearing down the plot and redrawing on every frame), but the data is transitioned in screen space. The result might be that the start and end states are correct and things in between are smooth but that the data doesn't track correctly with the axes between the two states.

That's not all that undesirable since it looks smooth, but here's where it got very difficult: When you drag the plot, it doesn't redraw things on every mouse event. If I recall correctly, it applies a transform and then when you mouseup it tears down the plot and redraws. This, I think, was the fundamental source of difficulty since the task is state management combined with two animation mechanisms: one mechanism is a requestAnimationFrame loop that updates an ephemeral axis-dragging sort of transform, and the other is browser svg transitions. I could definitely be convinced that perhaps a more promising pathway than the request animation frame loop is to use a matrix with browser transitions to transform the axes.

That's a few thoughts based on my recollections, but I'm glad to clarify and discuss further! I really tried to get it working and felt like it was very close, but I never quite was able to overcome the state management concerns and get things working well.

[alexcjohnson]

Thanks @rreusser for the extra context!

A concrete example of screen-space vs data-space transitions: Let's say you have a transition that both doubles the size of a bar, and halves the span of the axis it's drawn on. And let's further simplify to say the transition is linear. As a result the bar should end up 4x bigger than it started. If we do the entire transition in screen space, the bar will linearly expand, so halfway through it will be 2.5x its original size. But done in data space, the bar would grow linearly while the axis is zooming linearly, so there would be a quadratic component to the bar's size trajectory. Halfway through, it would be 1.5x * 1.5x = 2.25x its original size.

I'm sure there are cases where the distinction is bigger than that; but seems to me in general even if it's not 100% accurate, as long as all the pieces make the same choice we should be fine with screen-space transitions. Bars that are supposed to be connected to each other will be connected to each other throughout the transition; points that are supposed to switch positions will still switch positions, just perhaps not at the same fraction of the overall transition.

[rreusser]

One other thing to consider is log axes, which I think are similarly tolerable in screen space and as long as it's not require that data tracks the axes.

And just for the sake of argument, I don't know anything about the particular product requirements here, but I will note that the OpenGL approach is generally to use a model matrix and (of course) completely clear and redraw the entire plot on every frame. I don't know if it's possible or reasonable or feasible, but there is a possibility that this would actually be a comparatively easy thing to accomplish in WebGL as opposed to SVG which prefers the statefulness and persistence which make this difficult.

[rreusser]

Ah, now that I think about it, layout is easy in WebGL, but d3's management of state is what makes data transitions easy. Sigh.

[nicolaskruchten]

I don’t really follow this screen/data argument... “during a transition” the state of a vis is never “accurate” in the sense that if on my way from 2 to 3 (data) I always travel “through” 2.5 even though that’s not data per se.