Modify fill mode to inherit from the parent

[steveblock]

No description provided.

[birtles]

The first patch in this series is covered by:
https://dvcs.w3.org/hg/FXTF/rev/5544ee343a32

The second patch about adding an auto fill mode is something we're waiting for Steve's return to discuss.
See item 5 from http://lists.w3.org/Archives/Public/public-fx/2013JulSep/0009.html

[steveblock]

Thanks Brian. A few comments ...

3.13 + At a given moment, a timed item may be in one of three
3.14 + possible phases.
It might be useful to state explicitly that a TimedItem may not be in any of these three phases (eg if the local time is null).

3.262 + When the timed item or an ancestor is in its after
3.263 + phase, the timed item will produce the same <a
3.264 + title="transformed time">transformed time value as the last
3.265 + moment is is scheduled to be in play.
I'm not sure what you mean by 'or an ancestor'. If I understand the current spec text correctly, a TimedItem only fills in a given direction if the immediate n (maybe zero) ancestors are filling (not necessarily in the same direction, but see below for a question about this) and the remaining m (maybe zero) ancestors are active.

3.397 +

If the timed item is in the before phase,

3.398 +

3.399 + The result depends on the fill mode as follows.
3.400

3.401 -

3.402 - If the fill mode is <span
3.403 - class="prop-value">backwards or <span
3.404 - class="prop-value">both,
3.405 -

3.406 +

If the fill mode is <span
3.407 + class="prop-mode">backwards or <span
3.408 + class="prop-mode">both,

3.409 +

Return zero.

3.410 +

Otherwise,

3.411 +

Return null.

3.412 +

3.413 +

Consider the following case ...

• A TimedItem positioned within a parent such that its start time occurs after the parent's end time
• The parent ues forwards fill and the child uses backwards fill
• We sample the model between the end time of the parent and the start time of the child
• The parent will be in its after phase so will fill
• The child will be in its before phase, so we will evaluate the child at its start time

This is surprising, because the child doesn't support the (forward) fill mode being used by the parent. Compare the case where the model is sampled later such that the child is active: we would only evaluate the child if it used forwards fill like the parent. I suggest that we should only sample the child if it supports the fill mode currently being used by the parent. So in this example, we would only evaluate the child if it used fill both. WDYT?

[birtles]

Thanks Steve for the detailed review, I'll follow up on Thursday.

[birtles]

It's a good question, I need to think about it.

My thought at the moment is that how it's currently defined is right (by accident mind you, not because I really though that case through). The reason is that by saying "fill: backwards" you're saying "Fill until I start (unless,of course, my ancestors say no)". So in that case the animation never starts so it keeps filling forever.

I might not have quite understood though because you talked about the case where "the model is sampled later such that the child is active". Once we're sampling past the end time of the parent we're only ever going to pass the end time of the parent down. It's impossible to sample inside the child's active interval without moving the child in relation to the parent. But maybe I haven't understood?

Nevertheless there's almost certainly something wrong with that non-normative description of fill modes as you pointed out.

[birtles]

Hmm, I think the description of fill modes is partly correct:
"When the timed item or an ancestor is in its after phase..."

Two things that help explain it:

• A timed item can only in its after phase if its local time is not null
• A timed item can forwards fill while it is in its active phase

So you can fill even if you have no parent. You can also fill while you and your parent are in the active phase because somewhere up the tree there is a group in its after phase. If something up the tree is not either filling or in the active phase you won't have a local time so you won't fill.

I think the description fails to capture that last bit. It should probably say, "When the timed item is in the after phase, or when the timed item is in the active phase but an ancestor is in its after phase, the timed item will produce the same transformed time value as the last moment is is scheduled to be in play."

[birtles]

I've updated the spec with this description for now. Let me know what you think.
https://dvcs.w3.org/hg/FXTF/rev/bbc8623a111c

[steveblock]

My thought at the moment is that how it's currently defined is right (by accident mind you, not because I really
though that case through). The reason is that by saying "fill: backwards" you're saying "Fill until I start (unless,of
course, my ancestors say no)". So in that case the animation never starts so it keeps filling forever.
I don't agree. Considering again the example of a parent with forwards fill that's being sampled after its end time, with a child with backwards fill ...

• If the child ends before the end of the parent, its effect is only applied if it has forwards fill
• If the child spans the end of the parent, its effect is only applied if it has forwards fill
• If the child starts after the end of the parent, its effect is always applied.
  This seems inconsistent. I think it would make more sense if in all 3 cases, we only apply the child's effect if it has fill which matches the fill currently in use by the parent (in this case, forwards).

I might not have quite understood though because you talked about the case where "the model is sampled later
such that the child is active".
Sorry, I meant the case where the child spans the end of the parent, such that it's active at the parent's end time.

[steveblock]

I've updated the spec with this description for now. Let me know what you think.
https://dvcs.w3.org/hg/FXTF/rev/bbc8623a111c

Looks good, thanks

[steveblock]

The second commit, regarding auto fill mode, is now obsolete after this concept was added to the spec in https://dvcs.w3.org/hg/FXTF/rev/cb428dc9b757

Closing this pull request.