Re: [css-houdini-drafts] [css-animationworklet] Sending data to animators in worklet from main thread (#869)

The Houdini Task Force just discussed `Sending data to animators in worklet from main thread (here since it is closely related to the above)`, and agreed to the following:

* `RESOLVED: Add input properties, expose for the target, should work for input right now. And we'll pursue events / message channel later for output.`

<details><summary>The full IRC log of that discussion</summary>
&lt;iank_> Topic: Sending data to animators in worklet from main thread (here since it is closely related to the above)<br>
&lt;TabAtkins> github: https://github.com/w3c/css-houdini-drafts/issues/869<br>
&lt;iank_> majidvp: Similar issue as previous issue, we want to get some data from the main thread to the animation thread. We have this at startup with the options bag.<br>
&lt;iank_> majidvp: The issue is that there might be new data on the main thread that affect the animation, e.g. sizes of elements change.<br>
&lt;TabAtkins> q+<br>
&lt;iank_> majidvp: One idea is that do allow the options to be mutable, the main thread can up date the uptions, and it'll update the options on the animation thread.<br>
&lt;iank_> majidvp: The other options is using a postmessage port with the animator.<br>
&lt;iank_> flackr: If we want harmonize with css - we could do this with a property map.<br>
&lt;iank_> TabAtkins: Yes .<br>
&lt;iank_> flackr: There are several elements in play, and could read properties out of those elements.<br>
&lt;iank_> TabAtkins: When the animate() function get called, are there element references?<br>
&lt;iank_> majidvp: No the effect has a target, we don't expose that right now, but we could expose a styleMap.<br>
&lt;iank_> TabAtkins: You'd want to limit the number of properties.<br>
&lt;iank_> flackr: You could just expose all the same properties?<br>
&lt;iank_> hober: I agree.<br>
&lt;iank_> TabAtkins: Seems like we just want to expose inputProperties on the target for the effect? It doesn't let you pass information out however.<br>
&lt;iank_> majidvp: There are usecases for more stateful effects, and this stage I'm fine with not solving this.<br>
&lt;iank_> majidvp: These usecases are more important once you feed input events into animation worklet. But we don't have this yet, so its not pressing.<br>
&lt;iank_> bkardell_: A message channel is good for JS, but not good for CSS?<br>
&lt;flackr> iank_: another option is event dispatching<br>
&lt;Rossen_> q?<br>
&lt;TabAtkins> ack<br>
&lt;TabAtkins> zakim, ack<br>
&lt;Zakim> I don't understand 'ack', TabAtkins<br>
&lt;TabAtkins> q-<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;iank_> majidvp: Output could be events which fits nicely with the animations API.<br>
&lt;iank_> majidvp: postmessage is more generic, but has its own lifetime concerns, but you might not want to commit to that.<br>
&lt;iank_> TabAtkins: Add input properties, expose for the target, should work for input right now. And we'll pursue events / message channel later for output.<br>
&lt;iank_> Proposal: Add input properties, expose for the target, should work for input right now. And we'll pursue events / message channel later for output.<br>
&lt;iank_> RESOLVED: Add input properties, expose for the target, should work for input right now. And we'll pursue events / message channel later for output.<br>
&lt;iank_> break 15 mins.<br>
&lt;emilio> ScribeNick: emilio<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/869#issuecomment-499917946 using your GitHub account

Received on Friday, 7 June 2019 14:57:30 UTC