Le frame-based

Caractéristiques: La durée du tween est donnée en nombre de frames, et le calcul de chaque position se fait à chaque frame (typiquement, en écoutant l'évènement Event.ENTER_FRAME)
Concept: à chaque calcul, on regarde le nombre de frames écoulé depuis le départ par rapport à la durée en nombre de frames.
Avantages:

• On travaille avec des nombres entiers et invariants concernant la position courante dans le temps (nombre de frames écoulé) et la durée. Il devient donc possible de cacher une interpolation et donc de réduire les temps de calcul pour les interpolations suivantes utilisant le même couple équation/durée. En effet, une équation donnée sur une durée donnée se comportera toujours de la même manière. En gros, elle sera toujours à x% de son trajet à la n-ième frame, et c'est donc possible de le mettre en cache.

Inconvénient:

• L'intervalle de temps entre deux frames n'est pas fixe: si lors de l'exécution d'une frame un code oblige à ralentir le framerate, le player flash le fera automatiquement. Cela est probablement du à son mode d'exécution mono-threadé. Donc, sur une animation à 30fps, un tween d'une durée de 30 peut prendre plus d'une seconde... L'autre inconvénient, qui peut aussi être un comportement voulu, est que modifier le FPS global de l'animation revient à modifier la vitesse d'interpolation.

Le time-based

Caractéristiques: La durée du tween est donnée en seconde, et le calcul de chaque position est faite à un intervalle de temps donné (typiquement avec setInterval, ou plus "clean" avec la classe Timer).
Concept: un Timer lance le calcul de la nouvelle position toutes les x millisecondes. La base de calcul est le nombre de millisecondes écoulées sur la durée en nombre de millisecondes. Un TimerEvent.updateAfterEvent s'occupe de rafraichir l'affichage indépendamment du framerate.
Avantages:

• L'interpolation se fait sur une notion de temps. Bien que le Timer ne soit pas forcément extrêmement précis, c'est ce qu'on peut obtenir de plus proche. Ainsi, le taux de rafraichissement du tween peut même être configurable dynamiquement. Par exemple, on pourrait avoir un tween fluide sur une animation pourtant compilée à 2FPS.

Inconvénients:

• Justement, on ne contrôle pas la synchronisation anim/temps. Du coup, on surcharge beaucoup le moteur d'affichage du Flash Player, qui doit rafraichir l'affichage à chaque frame mais aussi à chaque calcul du tween. Il est également trés dur de synchroniser deux tweens: en effet, deux Timer de même durée peuvent dispatcher à plusieurs millisecondes d'intervalle, décalant d'autant les traitements.

Le "frame/time-based"

Caractéristiques: Mix entre le time-based et le frame-based: la durée du tween est donnée en secondes, et le calcul de chaque position se fait à chaque frame.
Concept: A chaque frame, on calcule le temps écoulé en millisecondes depuis le départ sur la durée totale en millisecondes
Avantage:

• On obtient les avantages combinés du frame-based (économie du moteur d'affichage) et du time-based (durée constante, indépendante du framerate).

Inconvénient:

• La fluidité de l'anim nécessitera un FPS élevé, comme pour le frame-based: fini les anims fluides à 2FPS!
• Comme pour le time-based, il est difficile de synchroniser les tweens entre eux, ou alors ils peuvent être synchronisés alors qu'ils ne devraient pas. En effet, admettons qu'une frame s'affiche toutes les 100ms exactement (je sais, un monde parfait n'existe pas, mais faites comme si). Le framerate est volontairement bas (10FPS) pour l'exemple. Deux tweens commencant exactement au même moment, et ayant des durées respectives de 820 et 880ms finiront en même temps, sur la frame 9. En effet, sur la frame 8, 800ms se sont écoulées, et le prochain calcul, qui déterminera la fin des deux tweens, se fera à la frame suivante, soit à 900ms.

Quel mode pour quel usage?

Le mode à utiliser est extrêmement propre à l'usage auquel il est destiné. Les moteurs existants utilisent souvent par défault la troisième option (frame/time-based), et proposent assez souvent la première (frame-based). Le deuxième reste la plus marginale, mais est tout de même proposée dans quelques moteurs/classes. Globalement, je suggèrerais:

• frame-based: si vous avez le contrôle de votre environnement de déploiement ou un framerate connu et fixe, ce mode ci devrait être le plus performant car travaillant sur des petits nombres et "cachables" (sauf aprés calcul dans l'équation). Egalement bien utile quand on a un besoin de synchronisation très précise (sauf avec les classes de Tween d'Adobe, voire poste précédent) entre différents tweens, ou quand on travaille avec beaucoup d'éléments issus de la timeline (trés fréquent quand on travaille avec un graphiste/animateur flash) avec lesquels vous devez vous caler.
• time-based: a priori le moins utilisé (y compris par les TweenEngine). Il est le moins performant car il rajoute du travail au moteur d'affichage du Flash Player. A utiliser si vous avez besoin d'une fluidité constante quel que soit le framerate. S'il vous faut uniquement des interpolations dont la vitesse est indépendante, voir le "frame/time-based".
• frame/time-based: utile pour avoir une durée a peu prés constante indépendamment du framerate. Très utilisé avec les vidéos ou les sons par exemple, il se positionne systématiquement au bon endroit selon le temps "réel" écoulé, quel que soit le nombre de calculs déjà effectués. En bref, même si l'appli "rame", votre tween sera plus ou moins synchro. Interessant aussi quand on ignore le framerate qui sera utilisé par l'application et qu'on désire conserver la vitesse des interpolations, si votre anim est chargée par un Loader par exemple (dans un site portail, un CMS, etc...).

Perso, quand je sais que mon SWF va tourner "tout seul", j'utilise beaucoup de frame-based, avec un "stabilisateur" de framerate (type celui d'André Michelle) pour être sur qu'il sera vu de la même manière par tout le monde...