Web Animations/Meetings/Meeting 11

Time, location: 14 Mar 17:00 PDT / 15 Mar 11:00 AEDT / 15 Mar 09:00 JST, #webanimations

Agenda

1. API / Object primitives
   • getMatchedCSSRules
2. Synchronization discussion
   • Synchronisation with script—results of investigation into RequestAnimationFrame etc.
   • Need to start designing declarative synchronisation

Actions arising

For Tokyo F2F:

• Brian to write up a draft spec of so-far-agreed-to parts of the API (primitive objects)
• Rik to prepare proposal for "declarative" synchronisation--i.e. animation groups part of API
• Brian to mail dom group about synchronisation options

Log

<birtles> woah, it's WA time!
<shans_> WOOO!
<birtles> thanks Shane! :)
<birtles> cool, ok, we can start
<birtles> oh, only two weeks until Toyko right!
<birtles> er Tokyo even!
<birtles> are you guys right for accommodation etc.?
<cabanier_away> yes, I'm all set up
<shans_> yep, all booked now
<birtles> great, can't wait!
<shans_> flights, hotel, all done
<shans_> should be awesome :)
=-= cabanier_away is now known as cabanier
<birtles> where are you staying by the way Shane?
<shans_> at the hotel you recommended
<cabanier> wasn't there a fancy google dinner planned too? :-)
<birtles> ok, same as Rik I think
<birtles> oh, I saw a ramen restaurant on TV last night--$120 a bowel :)
<shans_> haha
<birtles> (but it's a "member's only" restaurant)
<shans_> I am going to see what I can do re: the fancy dinner. I think it should be OK though.
<birtles> s/bowel/bowl/ --- ooh that's embarrassing
<shans_> heh
<birtles> ok, let's get started: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings/Meeting_11
<cabanier> I was wondering about that...
<birtles> 1) API / Object primitives
<birtles> 2) Synchronization discussion
<birtles> so I think we were in the middle of talking about getMatchedRules
<birtles> is that where we want to continue?
<shans_> yep
<birtles> anything else to add to the agenda?
<cabanier> no
<shans_> not for me
<birtles> if not, then Shane, did you get access to that bug?
<shans_> not yet. I'm in the process of trying though.
<birtles> or otherwise find out what the issue was?
<cabanier> it would be good to know what the security issue was and if it applies to our use case
<shans_> yes, I agree.
<birtles> yeah, I think we're pretty close to agreement here
<birtles> if I can summarise where I think we've arrived at
<birtles> I think we're pretty much on the same page except...
<birtles> rather than having a 'stack' in the API, I'd prefer to solve that more generally elsewhere
<birtles> so, if there's a path forward for getMatchedCSSRules I'd rather use that
<birtles> than define it ourselves
<birtles> if that API is not going ahead... then... I don't know
<birtles> so maybe we can't go any further forward on this discussion for now?
<shans_> I think that's correct. And I think we're in a pretty good place.
<shans_> as in, I think we can move on to animation addition, probably next meeting
<cabanier> I think we need an API close to getMatchedCSSRules if that one is out
<birtles> ok, I'm warming to the idea---especially if there exists a definition of how that API works somewhere
<birtles> but for now we just have to wait and see what the issues were there
<birtles> there's still heaps more to define in the API though, of course
<cabanier> OK
<birtles> like how the proposed element.getAnimators() etc. work
<shans_> I think we have a pretty good informal understanding of that
<birtles> ok, how do you want to proceed
<birtles> we need to flesh them out
<shans_> which means probably the best way forward there is to start drafting the specification?
<birtles> yeah, is that easier, for example, if someone fleshes out a proposal and we discuss it in Tokyo?
<shans_> I think so
<shans_> I think that'll be a good use of time in Tokyo
<birtles> ok, anyone want to do that? I don't mind doing it otherwise
<cabanier> I will be out for the next week...
<birtles> ok, I think Shane is already down to do the addition proposal?
<birtles> so maybe I should take this part?
<shans_> sounds good to me, if you don't mind doing it
<birtles> that's fine--I think we've worked out most of it already
<birtles> ok, so shall we move onto synchronisation then?
<shans_> yep
<cabanier> Ok
<shans_> I experimented on requestAnimationFrame last week
<shans_> want me to report on that?
<birtles> ok, so I have to confess, I haven't looked into rAF yet
<birtles> yes, please!
<shans_> so the executive summary is that, at least on WebKit, rAF handlers get put on the same queue as all other events.
<shans_> here are the details
<shans_> I set up a handler with a timeout of zero, that loops. So it's basically a yeild.
<shans_> yield.
<shans_> Inside that handler, I queue 100 secondary handlers, also with a timeout of zero. In other words, every time the outer handler runs, 100 events get added to the queue.
<shans_> Then, in parallel, I run a rAF callback that schedules another rAF - basically under ideal conditions this would be called once every animation refresh 
<shans_> so. None of the handlers do any work. If the rAF were on a priority queue, it would get called approximately the same rate as if the timeout system were not running, because there's plenty of opportunity for it to be scheduled.
<shans_> instead, what happens is that the rAF gets delayed. Furthermore, it is *always* scheduled at the end of a 100 callback block, never in the middle, which makes sense - those are all placed on the queue "at the same time" from the point of view of the browser, and hence the rAF callback can only ever end up on the end of that queue.
<shans_> any questions?
<birtles> yeah, that's kind of what I'd expect
<cabanier> that makes sense
<cabanier> it's called at the end of JS execution and right before the draw happens
<cabanier> so it's synchronous before the draw
<shans_> no, it's enqueued right before the draw is scheduled to happen
<shans_> but anything else in the queue will still run before it
<shans_> and I don't know whether the draw is delayed or not
<birtles> I think I need to summarise what we're trying to solve (for my own sake)
<birtles> we want to be able to synchronise script with animations so that
<birtles> a) you can make assumptions about what is on the stage when script runs
<birtles> b) you can schedule new animations / change existing ones and be sure they will be in sync
<birtles> is that about right?
<cabanier> yes
<birtles> (b) is technically possible already, but (a) is not
<cabanier> no
<cabanier> not with css
<birtles> ok, (b) is technically possible with SVG
<shans_> yep
<birtles> alright, so how was rAF related? we were trying to see if we can have prioritised events right?
<birtles> but how was that going to help?
<cabanier> we were looking into synchronous event handlers
<shans_> a) is not possible because there's an arbitrary delay between the animation event being generated and script being called
<cabanier> and rAF is one
<shans_> we had hypothesized that rAF was a synchronous event handler, and that we could do the same
<shans_> but in fact, it is not one
<cabanier> since it fires right before a draw and is not queued
<shans_> no, it is queued
<birtles> ok, and we know that synchronous event handlers are possible (DOMMutation) but there are perf issues involved in using that approach
<shans_> yes
<birtles> ok, I'd like to see if we have a DOM discussion group here and send a mail there
<cabanier> i thought the perf issues were because of the internal checking and the danger of recursion
<birtles> it's not so much recursion, but about forcing reflow several times per animation refresh
<cabanier> ok. so not really about them being synchronous
<shans_> that's a direct consequence of them being synchronous
<birtles> there may be ways to work around it---I don't think we need to rule out synchronous handlers completely yet
<cabanier> anyway, I think if we can pause the animation, the event can be async
<cabanier> then there's just the risk of more stuttering
<birtles> maybe that's why we looked at rAF---because of the risk of stuttering
<birtles> i.e. pause the animation, dispatch an async event but prioritise it
<birtles> as a compromise solution
<shans_> yes, that may have been it. But rAF doesn't actually do prioritisation
<birtles> but it turns out there are no prioritised events (yet anyway)
<cabanier> yeah and since rAF is frame by frame based and not time based, things will still go out of sync
<birtles> so I'd like to take an action to put this discussion into a mail to a suitable group
<birtles> probably, mozilla.dev.tech.dom
<shans_> sounds good
<birtles> but I think we can still proceed with synchronisation discussion here
<birtles> ACTION Brian to mail dom group about options for synchronisation animation with script
<birtles> I think we can still start to design how declarative synchronisation should work
<shans_> ok
<birtles> I mean, from an API point of view, how do we want animations to sync with each other
<birtles> we've been talking about how to synchronise script and animation, but what about just synchronising two animations
<cabanier> I proposed an new keyword so you can group animations
<cabanier> css: animation-group
<birtles> ultimately, that should be something we can map to SVG's existing features for that, but that's a secondary consideration
<birtles> ok, so I thought animation-group was just for pause control?
<cabanier> anything within a group will pause if there is an animation event handler called
<birtles> are you talking about then in terms of time containers though?
<shans_> wait, wouldn't pause control be part of synchonization?
<cabanier> pause is different
<cabanier> you can pause an animation but leave others running
<birtles> yeah, but pause control doesn't tell you "how" animations within that group get synchronised
<cabanier> I see that more as part of the API
<cabanier> how so?
<birtles> I think we have a few use cases to consider, e.g.
<birtles> I want animation A to start at the same time as animation B
<birtles> that's probably the simplest use case
<cabanier> through script? Not declaratively right?
<birtles> that's the question I guess
<birtles> is this a feature we want to support at the API level
<birtles> I assumed "yes"
<birtles> but no?
<cabanier> I think that should be script based...
<shans_> definitely we want to support this in the API
<shans_> having declarative support would be nice too, though? Being able to define bundles of animations that start together is pretty important I think
<birtles> yeah, I think that's important
<cabanier> wouldn't they just share a rule?
<cabanier> and changing the rule would start all of them
<birtles> but what if they're completely different animations?
<birtles> and I think you want to be able to have many complex arrangements such as, "A starts when B finishes", "A starts 2s after B"
<cabanier> yeah
<cabanier> but they need to be grouped somehow
<birtles> yeah, I think we can do that
<birtles> so, about a year ago, I proposed dropping syncbase timing from SVG and using time containers
<cabanier> the rule would be 1 animation
<birtles> (http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Proposal:_Remove_syncbase_timing_and_replace_with_time_containers)
<cabanier> not 2 with syncs
<birtles> basically, by using time containers (a kind of grouping) you can get most of the arrangements possible with syncbase timing
<birtles> but not all
<birtles> but it's much simpler and I think maps to CSS better
<birtles> so maybe we can have some similar sort of grouping in the API?
<cabanier> yes, that looks reasonable
<cabanier> and close to what I proposed on cc animations with child selectors
<shans_> do you have a link to that, Rik?
<birtles> do you have any details written up anywhere?
<birtles> (same question :) )
<birtles> I'm just having trouble visualising it
<cabanier> I do not... I just wrote it in email
<cabanier> I can work on that.
<birtles> that would be great
<cabanier> probably for Tokyo because I will only be in the office for a couple of days
<birtles> ok, that's fine
<shans_> I think this stuff needs a face-to-face to discuss anyway
<shans_> more to the point: a whiteboard
<birtles> yeah, ok
<birtles> I think this might work
<shans_> but, for the record, I am definitely in favour of losing syncbase timing
<birtles> I mean having groups in the API seems to map well to CSS
<birtles> yeah, I think we can push the group/time container approach as the way forward for SVG too
<cabanier> shane, me too
<shans_> Brian, what are the things that you can do with syncbase but not with time containers?
<birtles> and I think SVG can continue supporting syncbase timing as a deprecated feature just by using a specialized Animator
<birtles> syncbase timing gives you these arbitrarily complex networks
<birtles> that's half the problem
<birtles> there's no requirement for nesting and hierarchy
<shans_> so e.g. A start=B.end and B start=A.end? that sort of thing?
<birtles> that one's easy I think...
<birtles> <seq repeatDur="indefinite">
<birtles>   <animate/>
<birtles>   <animate/>
<birtles> </seq>
<shans_> ok, what's an example of something you can't do then?
<birtles> hmm... I don't know if I can generate a succint one here, but basically you can have <animate begin="a.begin; c.end+2s, d.begin-3s; ...">
<birtles> and a, c, d might also have similar conditions
<birtles> and I think to achieve that with containers you'd have to duplicate animations which would change the semantics
<birtles> I *think*
<shans_> hmm, righto
<shans_> unless you could have use references
<birtles> yeah
<cabanier> seems that things get complicated fast...
<birtles> still, I think the cases you can't do, are not so important... but I haven't done any thorough analysis to say that with conviction :)
<birtles> let's wrap up synchronisation
<birtles> I think we're mostly in agreement about the grouping approach?
<birtles> and about staying away from syncbase timing
<cabanier> yes
<shans_> definitely
<birtles> so Rik is going to prepare a more concrete proposal for Tokyo
<birtles> but Rik, can I ask that you don't make it too CSS specific? I mean, I want to see the CSS mapping, but I'd prefer the API is useful beyond CSS?
<cabanier> yes, a proposed CSS syntax for grouping
<cabanier> OK
<birtles> great
<birtles> and I'm going to ask about script synchronisation options
<cabanier> will you email the link to discussion group?
<birtles> so perhaps we can leave the synchronisation discussion there for now
<cabanier> or is it internal?
<birtles> I think this is the group: http://groups.google.com/group/mozilla.dev.tech.dom/topics
<birtles> pretty much nothing is internal in Mozilla :)
<cabanier> yeah, I was reading this one today: https://groups.google.com/forum/#!topic/mozilla.dev.platform/-xTei5rYThU/discussion
<birtles> if you make something internal you get 100 complaints "why isn't this open?" :)
<shans_> ok, thanks guys.
<shans_> yep.
<birtles> alright, next meeting?
<birtles> Rik, are you away all next week?
<cabanier> I will be back on wednesday
<shans_> I can't do Wed next week, OK apart from that
<shans_> just let me know what you guys decide :)
<birtles> ok, see you Shane!
<birtles> thanks!
<cabanier> Next week, same time?
<birtles> yeah, does that work for you? you'll be in the office on Wed?
<cabanier> yes
<birtles> ok, same time it is
<birtles> thanks Rik!
<cabanier> are you switching to daylight savings?
<birtles> no, Japan doesn't have it
<cabanier> ah
<birtles> and Sydney is not for a few weeks I think
<cabanier> Ok, see you next week!
<birtles> end of March or so
<birtles> ok, see you!