- From: Majid Valipour via GitHub <sysbot+gh@w3.org>
- Date: Wed, 29 Aug 2018 18:19:33 +0000
- To: public-houdini-archive@w3.org
_From @dbaron on April 9, 2018 13:48_ The beginning of the IRC discussion on this topic, during which IRC went down and caused state loss, was this: <details><summary>See the rest of the IRC log</summary> <dael> Topic: Animation Worklets<br> <majidvp> https://github.com/WICG/animation-worklet/issues/87<br> <dael> majidvp: Right now when you have an animation worklets everything you register is considered stateful. Some of the effects you don't need to have local state. If your animation doesn't need local state it's good to know.<br> <dael> majidvp: When it's stateful you need to go in sequence.<br> <dael> majidvp: Ask was to be able to make the distinction explicit.<br> <dael> majidvp: Proposal from astearns was to have a state object. This is similar to layout API and caching property.<br> <astearns> s/astearns/asajeffrey/<br> <astearns> (I think)<br> <dael> majidvp: Proposal is to have a state object on the animation which the impl uses to 1) if the state object is available it means it's stateful and not a pure animation and 2) previously we had an onDestroy callback which allowed the animation to serialize. This proposal allows us to get rid of that callback. We can just serialize the state and move it when going between.<br> <dael> smfr: Seems odd to have the state...Once you computed the state the first time you might want it to be read only<br> <dael> flackr: If you want that you should pass that in rather then computing it. i'ts a static input.<br> <dael> shane: Is that too restrictive?<br> <dael> flackr: Maybe? If you had a state that didn't change regularly you could imagine allowing parallel execution until state changes. I don't know if that's a common use case.<br> <dael> majidvp: If you have a state it means we opt you out of run in parallel. Could be possible we have a state and until it changes you're in parallel. Let's be more conservitive and if there are use cases we can relax.<br> <dael> flackr: Only concern with relaxing is detecting the state change. You have to detect or have an API to say I changed.<br> <dael> majidvp: Initial version was to have a state boolean which would indicate if it allows parallel execution. We can do something like that in the future with the boolean<br> <dael> smfr: isStateful is a better description the hasState<br> <dael> majidvp: Current proposal is if the state object exists it means it's stateful, not sue isSateful or hasState.<br> <dael> smfr: Can you show us the API?<br> <dael> majidvp: First argument to the consctructor.<br> <dael> majidvp: It would make sure that if you have an actual state you set it on the state object so when you move between global context you keep your state. If we kill your instance your state sticks.<br> <dael> majidvp: You can hold onto your state.<br> <dael> birtles: You look at length of constructor funciton?<br> <dael> majidvp: Every time we animate you we call the state getter. If that provides an object that's your state and it means you're stateful. Every time we destroy the global scope that state will be passed in to you<br> <dael> majidvp: It's only when you register the animation. First time you're called it's null, as we animate you can change.<br> <dael> birtles: If you're looking at length of constructor I understand that, but how do you know.<br> <dael> majidvp: You're looking at spec, this is a proposal. You get the state and the options.<br> <dael> birtles: The difference between an animator and a pure animator is clear to anyone that works in React.<br> <dael> shane: It's an import and distinction too.<br> <dael> shane: Maybe an flag is acceptable<br> <dael> majidvp: One thing about taking this flag is it can change over time. YOu start as stateless and at some point you do have a state from that point on you're stable.<br> <dael> shane: Can you clear state?<br> <dael> majidvp: Yes.<br> <dael> shane: This would be useful with impl a state machine. You can make a decision about what the next animation is.<br> <dael> birtles: What if you have several frames at ones and one is stable.<br> <dael> shane: You're stateless if it's many frames. If one frame is stateful it stops there.<br> <dael> majidvp: The example from Jan. they run in parallel and if they see state they can't treat it the same.<br> <dael> birtles: They're saying it's not impl-able. You're either stateful or stateless, choose one.<br> <dael> majidvp: Personally I'm fine for it to be static. Most of the use cases weren't specifically stafefull or stateless, but it did change.<br> <dael> flackr: Let's say we go with something static now, how may it change?<br> <dael> shane: If you register yourself as stateful or stateless you can register yourself as auto and change.<br> <dael> flackr: Right thing to do is statis route until we have feedback.<br> <dael> majidvp: iStateful is the proposed name?<br> <dael> smfr: Yeah.<br> <dael> shane: Do we want State or Stateful?<br> <dael> majidvp: It would be a static property on the animator class.<br> <dael> birtles: In the current spec you ask to register a function and that will change you pass something else?<br> <dbaron> shane: It should be enum values so it's extensible.<br> <dael> majidvp: It's a function callback. It's a class similar to Paint. This is a class that implements callback interface. In the class there's a static property of isStateless<br> <dael> birtles: I'm wondering if we can just look at functions<br> <dael> majidvp: My understanding is that there is slighly different syntax for stateful and stateless. If you're stateful component it's a class.<br> <dael> majidvp: I think in this case static attribute on the class seems usable enough<br> <dael> shane: Makes it explicit<br> <dael> majidvp: There's nothing like this on other spec where we can extend<br> <dael> Rossen: What did we narrow down tp?<br> <dael> Rossen: Do we keep going with isStateful?<br> <dael> majidvp: I think it was have explicit attribute on the class, I don't know what hte name should be. If you want an enum stateful isn't a good name.<br> <dael> majidvp: An enum is the right idea, I'll bikeshed the name on the issue.<br> <dael> Rossen: WE want to have the state state on the class, name pending bikeshed.<br> <dael> Rossen: Objections?<br> <dael> birtles: I'd like to look at other options. I'm not 100% sure we need the attribute.<br> <dael> shane: If we want to preserve possibility of switching we need it.<br> <dael> birtles: I think there's more enquery to do.<br> <dael> Rossen: Before we resolve on the big issue, we can resolve on having the state always be one by construction. Either always stateful or not.<br> <dael> Rossen: For now we're not allowing a dynamic state. Let's resolve on that and then figure out if we need to expose it.<br> <dael> Rossen: Objections to not having a dynamic ability on animations, they're either stateful or not.<br> <dael> RESOLVED: not have a dynamic ability on animations, they're either stateful or not.<br> <dael> Rossen: Do we need to expose this is the next question.<br> <dael> majidvp: We want to give author a way to differentiate between the two. I'm in favor of exposing and letting authors say what their animation is. Mechanism I'm impartial. WE can have the bool on the class, we can have different parent classes.<br> <dael> Rossen: Because you're basing things on the fact that people can take advantage of this performance, can you give us an example of that?<br> <dael> majidvp: If you want to impl parallax. It doesn't have state, just translates input to state. If we say it's stateless the browser can produce more animations and avoid running JS.<br> <dael> majidvp: It's more obvious when anmation is time based. In one animation worklet you run the thread once and get multiple frames. For stateful you can't do that because producing one frame might not be there in the next seq. You're losing some performance benefit.<br> <dael> majidvp: Our impl doesn't run in parallel.<br> <dael> Rossen: By construction you're impl will know if it's stateless or stable<br> <dael> majidvp: How would you know.<br> <dael> smfr: Pasing state in constructor.<br> <dael> Rossen: Oh. So we resolved by construction they are stateful or stateless So you know if this is one or the other. You don't need to ask anymore. Attribute you'd need in case you change your mind, but I don't see anything dynamic.<br> <dael> flackr: How do you construct it?<br> <dael> Rossen: You tell me.<br> <dael> flackr: This was a static class to say.<br> <dael> majidvp: Other option would be construction for worklet takes in a state object that's passed into an animation instance. If it's undefined or null it's stateless.<br> <dael> Rossen: Yeah.<br> <dael> majidvp: We have an opbect called options. We use it to pass things the animation needs to know. It's similar. I wouldn't mind that.<br> <dael> Rossen: That way everyone is kind of happy. birtles is happier.<br> <dael> birtles: I was looking for other options, but yeah. I put on the issues two other things about the constructor. May be other possiblilites with switching.<br> Connection closed unexpectedly: Server going down<br> <surma> \o/<br> <dael> majidvp: You don't have to provide when you do the animation that you have 2 arguments it's stateful<br> <TabAtkins> esprehn: Can you op rossen or astearns and de-op yourself?<br> <RRSAgent> logging to https://www.w3.org/2018/04/09-houdini-irc<br> You invited logbot to join #houdini<br> <dael> majidvp: birtles proposal in the issue is nice and ergonomic. If it has 2 arguments it means second is tate<br> <dael> majidvp: Number of arguments.<br> <dbaron> Topic: Animation Worklets, continued<br> <dael> iank_: You can't look at the shape of arguments.<br> </details> -- GitHub Notification of comment by majido Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/812#issuecomment-417053898 using your GitHub account
Received on Wednesday, 29 August 2018 18:19:35 UTC