Adjust range start/end based on the duration and delay of the animation

[sebmarkbage]

When different animations in a View Transition have different durations, we shouldn't stretch them out to run the full range of swipe. Because then they wouldn't line up the same way as when played using plain time.

This adjusts the range start/end to be what it would've been when played by time. Except since we are playing animations in reverse, the animation-delay is actually applied from the range end and then the duration from there to get closer to the start.

Reverse the range if the original animation was reversed.

Interestingly, the range it takes can be adjusted by what is in the viewport since if a long duration animation is excluded then everything else adjusts too.

I left some todos too. We really should also handle if the original animation has multiple iterations. Currently we only play those once.

[react-sizebot]

Comparing: 6377903...4d0def4

Critical size changes

Includes critical production bundles, as well as any change greater than 2%:

Name	+/-	Base	Current	+/- gzip	Base gzip	Current gzip
oss-stable/react-dom/cjs/react-dom.production.js	=	6.68 kB	6.68 kB	=	1.83 kB	1.83 kB
oss-stable/react-dom/cjs/react-dom-client.production.js	=	515.13 kB	515.13 kB	=	91.78 kB	91.78 kB
oss-experimental/react-dom/cjs/react-dom.production.js	=	6.69 kB	6.69 kB	=	1.83 kB	1.83 kB
oss-experimental/react-dom/cjs/react-dom-client.production.js	+0.14%	615.31 kB	616.17 kB	+0.20%	108.87 kB	109.09 kB
facebook-www/ReactDOM-prod.classic.js	=	647.04 kB	647.04 kB	=	114.37 kB	114.36 kB
facebook-www/ReactDOM-prod.modern.js	=	637.32 kB	637.32 kB	=	112.79 kB	112.79 kB

Significant size changes

Includes any change greater than 0.2%:

(No significant changes)

Generated by 🚫 dangerJS against 4d0def4