Re: Question about animate-elem-201-t

Julien Reichel:
> Hi Olaf,
>
> > Why not to add intstance times, when they are known:
> > There might be a different event that prevent the syncbase
> > value to exist as an instance time.
> > And it is simpler for implementors to create the instance time lists.
> > In the section referenced it is therefore noted:
> > 'syncbase-values and media-marker-values are treated
> > similarly. These conditions do not yield an instance time
> > unless and until the associated syncbase element creates an
> > interval. Each time the syncbase element creates a new
> > interval, the condition yields a single instance time. The
> > time plus or minus any offset is added to the list. '
>
> Ok, I got your point ( I still need more to be convinced :-) )

Thinking about it a little bit more and looking in details, what is
really written, I think, I have to modify my previous argumentation
a little bit.

The point is that it is noted:
'These conditions do not yield an instance time
unless and until the associated syncbase element creates an
interval.'

This means indeed that it is possible to get a visible effect from
the syncbase end and a negative offset, because the information
about begin and end of an interval is already propagated 
(and in case of end maybe corrected several times), before the
interval is finished.

>
> So let me consider the attached example (also copied at the end of the
> mail in case the mailing list doesn't let it trough)
>
> According to your explanation, all 4 square should stay green all the
> time. Is it correct ?
>
> However, if we considerer that the timeline is build on opening the
> document, the 2 square on the left should change to blue after 2
> seconds. The two square on the right should never change to red, as the
> beginEvent is incontestably trigged only when it happens. Is my testset
> correct ?
>
> Now, if that is correct it means that using negative offset in bend or
> end attribute will not let you start an action before the trigger
> actually happens. So for instance if I want to trig a fly out on a video
> object writing something like:
>
> <video xml:id='videoid' ...><animate attributeName='x' from='0' to='200'
> dur='1s' begin='videoid.end-1s'

/>

> </video> 
>

If we have 
<video xml:id='videoid' ... begin="0s" dur="60s">
<animate attributeName='x' from='0' to='200' 
dur='1s' begin='videoid.end-1s'/></video>

> It will not cause the video to fly to the right at the last second.

This should work, because at 59s the information about the
end of #videoid is already available as syncbase value.

Lets have a closer look on this one:
<video xml:id='videoid' ... begin="100s;140s" dur="60s">
<animate attributeName='x' from='0' to='200' 
dur='80s' begin='videoid.end-90s'/></video>

This causes some more problems.
At which time the first interval for animate is 'created'?
As far as I understand SMIL, this happens already at ~0s,
therefore the first interval is [70s; 150s). After the creation
of the interval, the viewer just has to wait until 100s, if
something else happens. If nothing happens up to 70s
the dependent animate animation does not get any 
updates and starts therefore. 
At 140s the end condition is updated to 140s, but this is 
obviously already too late to correct the times for the 
dependent animate animation. 

A second interval has to be considered at 140s with the
second begin of #videoid and would result in [110s; 190s).
However because 110s is before 140s, the following
SMIL condition is not fulfilled:
'If there is another legal interval defined to begin at or after 
the just completed end time, a new interval will be created.'
The current interval could be only ended now at 140s, but
not at 110s, therefore the second interval should be ignored.


>
> Is it correct ?
>
> If yes, then this is very inconvenient.
>
> In this case I do not really understand the difference between
> 'id.begin' and 'id.beginEvent'. But I believe this is the subject of
> another email on another mailing list :-)

For events:
'These conditions do not yield an instance time unless and until the 
associated event happens.'
For syncbase values:
'These conditions do not yield an instance time unless and until the 
associated syncbase element creates an interval.'

For events really everything happens, if the event happens,
for syncbase values something already happens, when the
interval is created, this can be earlier, but not before the 
previous interval is finished.
Something like this happens in the test suite sample too
due to the multiple begins finishing the previous intervals for the 
syncbase animation.


Oh - the Opera crash is only related to bug-286635
(beginEvent crash), already known and unfixed
for about 10 months, nothing to worry about obviously ;o)

Olaf

Received on Saturday, 12 July 2008 12:52:18 UTC