Issues with dynamicFlow

I believe dynamicFlow and section B are not well specified, and do not fit with the model in that it seems to require state to be maintained between two synchronic slices.

Some issues I have:

How is content comparison for the purposes of B2 step 2a-e determined? If it is logical tree comparison, then how is difference/equality defined for two arbitrary trees which may or may not share a common subtree - what happens for example to style attributes in the tree; or can no style animation happen for scrolling text?

How do you determine which node in tree B should correspond to the node(s) which generated the "most logically prior content presently visible" - maybe bidi processing is required to reorder the due to an element being elided, does the scroll go back to that element?

What indeed is 'before' in this context, and what is 'logically prior'.

How do pixel units fit into a logical tree comparison?

Is case 2a even possible? why would there be two synchronic slices for a region that have no differences? If it is possible, what happens for runs of 3 or more such slices?

I'm also not clear what times n where Tk < n < Tk+1 are actually defined (leaving aside the issue that no intermediate states are defined in discontinuous smpte mode, or how they would be rounded to smpte frames).

Since the amount of content in the flow buffer seems to alter the fill rate. What happens when this changes the fill interval? Is it possible for the fill to effectively 'go back in time'?
e.g Lets say we are computing the scroll state between two synchronic slices Tk=10s and TK+1 = 11s with a given flow rate of 2.

if at point Tk flow buffer contains 20 fill units; there are 10 logical steps.
If at point TK+1 flow buffer contains 30 fill units; there are 15 logical steps.

Say we are at step 5, and we discover that one of the conditions in B4 applies, the flow buffer changes, and we went from 5/10 (i.e. 10.5s - half way through the scroll) to 5/15 (10.333s - less than halfway); is the 'next' fill 'tick' 10.4s? if so then since this is less than 10.5 should not the flow buffer revert back to 20 units?. Or perhaps we skip to 10.533 - missing out a couple of steps half way through the second scroll? If on the other hand the flow buffer changed to be 10 units, would we be done?

If we go backwards, should previously scrolled content reappear?

There are even more interactions if the clear timing interval is also changing with respect to the fill buffer.

The more I look at it, the more I feel that this mechanism is not a good fit with the SMIL/Timed text model.

IMO pixel level smooth scrolling aspects of dynamicFlow would be best modeled by animation of a canvas origin property on region (& perhaps introducing SMIL's <animate>). The character/word/line inflow/outflow is adequately modeled already by <span>.


Sean Hayes
Media Accessibility Strategist
Accessibility Business Unit
Microsoft

-----Original Message-----
From: Glenn A. Adams [mailto:gadams@xfsi.com]
Sent: 19 April 2009 1:39 PM
To: Sean Hayes; Public TTWG List
Subject: Re: ISSUE-58 (showBackground animateable): shouBackground should not be animateable [DFXP 1.0]


i will go ahead and make all style properties animatable; tts:dynamicFlow
can be easily handled by defining that a change in its value causes a reset
of the fill and clear flow timers; regarding dynamic flow having state
across significant synchronic intermediate documents, i believe i have dealt
with that previously in Section B.2;

g.

On 4/19/09 5:26 PM, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:

> Interesting you should say that, I had exactly the same thought last night.
> One of the original design principles was that timed text display should be a
> function of time, i.e. without state. The reasoning behind having attributes
> non-animateable was that it might be too expensive in terms of re-flow etc,
> but if at each moment in time the entire tree is effectively made anew. Then
> this reasoning seems unsound.
>
> So I support the motion.
>
> The only one I have some doubts about is dynamicFlow, because it seems to
> operate somewhat outside the same timeline, and thus have state across time
> ticks. Which is also why I think dynamicFlow should be dropped, or
> substantially reworked in order to fit with the above model.
>
> Sean Hayes
> Media Accessibility Strategist
> Accessibility Business Unit
> Microsoft
>
> -----Original Message-----
> From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On Behalf Of
> Glenn A. Adams
> Sent: 19 April 2009 7:11 AM
> To: Public TTWG List
> Subject: Re: ISSUE-58 (showBackground animateable): shouBackground should not
> be animateable [DFXP 1.0]
>
> i propose we take a different approach: make all styles animatable
>
> i note that at present, the following are defined as being non-animatable:
>
> tts:direction
> tts:displayAlign
> tts:dynamicFlow
> tts:extent
> tts:origin
> tts:overflow
> tts:unicodeBidi
> tts:writingMode
>
> in contrast, all of the (remaining) following properties are defined as
> animatable:
>
> tts:backgroundColor
> tts:color
> tts:display
> tts:fontFamily
> tts:fontSize
> tts:fontStyle
> tts:fontWeight
> tts:lineHeight
> tts:opacity
> tts:padding
> tts:showBackground
> tts:textAlign
> tts:textDecoration
> tts:textOutline
> tts:visibility
> tts:wrapOption
> tts:zIndex
>
> there doesn't seem to be any principled reason for making any of the above
> properties non-animatable; in fact, we have recently assumed that tts:origin
> (and perhaps tts:extent) is animatable in order to move a region to a new
> location; also, the following seem to be inconsistent on the surface:
>
> * tts:textAlign is animatable, but tts:displayAlign is not
> * tts:wrapOption is animatable, but tts:overflow is not
>
> if one supports animation for one property, then it should be fairly trivial
> to support animation on any other property;
>
> therefore, i propose we make all the style properties animatable, which will
> make usage and authoring less subject to special case exceptions;
>
> glenn
>
> On 4/18/09 3:03 AM, "Timed Text Working Group Issue Tracker"
> <sysbot+tracker@w3.org> wrote:
>
>>
>> ISSUE-58 (showBackground animateable): shouBackground should not be
>> animateable [DFXP 1.0]
>>
>> http://www.w3.org/AudioVideo/TT/tracker/issues/58
>>
>> Raised by: Sean Hayes
>> On product: DFXP 1.0
>>
>> tts:showBackground is listed in the specification as animateable. I cant see
>> why this is necessary. Unless we have a use case for this I propose it be set
>> to animateable: none
>>
>>
>>
>
>
>

Received on Monday, 20 April 2009 15:30:15 UTC