- From: Kari Pihkala <kari.pihkala@gmail.com>
- Date: Wed, 15 Jul 2015 09:13:57 +0300
- To: Shane Stephens <shans@google.com>
- Cc: Brian Birtles <bbirtles@mozilla.com>, "public-fx@w3.org" <public-fx@w3.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
2015-07-15 9:04 GMT+03:00 Shane Stephens <shans@google.com>: >> > This is >> > slightly better than start time ordering, but not much - for example, it >> > means that if you've started other animations in the wrong order with >> > respect to the animation you're about to start, you are out of luck >> > unless you want to apply potentially global updates (your only available >> > operation is to move an animation to the top of the priority stack). For >> > another example, how do you slot a newly played animation in between a >> > high-priority animation and a low-priority one? You can't without >> > restarting the high priority animation. >> >> This is where creation-time ordering seems weakest. With TFI you can >> shuffle animations by restarting them (saving their currentTime in >> between if needed). With creation-time ordering you have to create >> entirely new animations. The again, the same problem exists for FTFI. I >> guess clone()-ing is not that bad as an interim measure. > > > Right, we definitely need that ordering tweak at some point soon. A method to manually control the order would really be the best choice. For instance, by inserting after/before another animation in an animation list or by setting a priority or ... That way it would be easy to write a wrapper over it to implement either creation time ordering or FTFI. The user can decide which model he uses by selecting different wrappers. I hope that the animation API is a low level API, which enables building higher level abstractions over it. Don’t build an API with a high level abstraction, because it will always be wrong for some users. BR, Kari
Received on Wednesday, 15 July 2015 06:14:25 UTC