- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Wed, 15 Jul 2015 13:59:20 +0900
- To: Shane Stephens <shans@google.com>, "public-fx@w3.org" <public-fx@w3.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>
Hi Shane, I definitely agree start-time scheduling is problematic. I was just interested in why creation-time ordering is better, particularly as opposed to first-transition-from-idle (let's call it FTFI). The first two points of your mail were about the problems with TFI which I agree are weaknesses so I'll just jump to the third point which I think touched more on the advantages on creation-time ordering. On 2015/07/15 8:37, Shane Stephens wrote: > (3) It is idiomatic to create animation resources separately from their > scheduling. We've already seen a desire to do things like this with > declarative animation and triggers, or with time sheets. It seems equally true to say that its idiomatic to create animation resources separately from their priority. > Creation time ordering ties animation priority to animation creation, > which means that you think about the order in which animation resources > will layer at the point where you're creating the resources. That seems odd to me. It seems more natural to set up the animations with all their properties and then think about how to combine them. That's where I was going with the FTFI proposal. > In contrast, TFI ordering means you need to think about animation > resource ordering at each point that you start an animation. Again, having to think about priority when you create animations seems unfortunate. That's something you'll often want to delegate to a factory method of some kind, and then take care of the controlling logic elsewhere. > 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. > I hope these arguments give a good sense for why I'm opposing the idea > of moving away from creation-time ordering. Any questions / > counter-arguments? I guess I'm not thrilled with any of the options. I was hoping I was forgetting something amazing about creation-time ordering! As Kris says, and as we've often acknowledged, we'll need a mechanism for explicitly setting priority in the future. Until them maybe creation-time ordering is ok. I was hoping to see how its better than FTFI but they seem much of a muchness to me. Best regards, Brian
Received on Wednesday, 15 July 2015 04:59:49 UTC