W3C home > Mailing lists > Public > www-smil@w3.org > April to June 2007

Re: Urgent please

From: Sjoerd Mullender <sjoerd@acm.org>
Date: Sun, 17 Jun 2007 12:40:12 +0200
Message-ID: <46750F8C.7030509@acm.org>
To: Jack Jansen <Jack.Jansen@cwi.nl>
CC: ___ <berlusconigay@gmail.com>, "'SMIL List'" <www-smil@w3.org>

On 06/17/2007 12:47 AM, Jack Jansen wrote:
-- 
Sjoerd Mullender
> It is a bit difficult to read your code, but the problem may be that
> your mixing up scheduled end and event-based end.
> 
> if bt_A.activateEvent is fired then two things happend immediately:
> 1. B_par ends
> 2. B_text2 ends
> 
> You're expecting that the end of B_par raises B_par.end which in turn
> leads to B_text2 ending. This seems like a reasonable expectation, but
> I'm not 100% sure it is correct. "B_par.end" is different from
> "B_par.endEvent": the first one is scheduled and the second one is
> event-based.
> 
> The exact distinction between those two mechanisms can be found in the
> SMIL standard (in the timing section), but the hand-waving explanation
> is that scheduled timing is pre-computed into the timegraph (similar to
> seq children starting when their predecessor ends, etc) whereas
> event-based timing happens on the fly (the timegraph is computed as if
> end="indefinite", I think).
> 
> I'm not sure whether the standard specifies what should happen in this
> case (a scheduled timing relationship depending on an event-based timing
> relationship), maybe Sjoerd or someone else who understands this better
> than me can explain?

When an element ends because of an event, the end condition is
reevaluated and repropagated.

> But what I am sure of is that with a construct like this you're
> descending into the deep damp cellars of the SMIL timing model, so
> you're quite likely to stumble upon a bug. My suggestion would be to
> change the "B_par.end" into "B_par.endEvent", thereby making everything
> event-based, and hoping that that fixes the problem.
> 
> On  16-Jun-2007, at 23:56 , ___ wrote:
> 
>>
>> This situation is extremely easy to understand, please give me a reply
>> please. I'm using real player.
>>
>>   <body>
>>     <par dur="indefinite">
>> <par id="A_par" begin="bt_A.activateEvent" end="bt_B.activateEvent">
>> ......
>> </par>
>> <par id="B_par" begin="bt_B.activateEvent" end="bt_A.activateEvent">
>> <par id="B_par_text1" begin="0s;arrow_b.activateEvent"
>> end="B_par.end;arrow_f.activateEvent">
>> <textstream id="B_text1" src="..."
>> rn:backgroundOpacity="0%" transIn="fade_1" region="text_B_a"
>> end="B_par_text1.end;bt_A.activateEvent" fill="freeze"/>
>> <textstream id="B_text2" src="..."
>> rn:backgroundOpacity="0%" transIn="fade_1" region="text_B_b"
>> end="B_par_text1.end;B_par.end" fill="freeze"/>
>> </par>
>> <par id="B_par_text2" begin="arrow_f.activateEvent"
>> end="B_par.end;arrow_b.activateEvent">
>> .......
>> </par>
>> </par>
>>     </par>
>>   </body>
>> </smil>
>>
>> Why when B_text1 and B_text2 are visible, and i click on bt_A, only
>> B_text1
>> disappear?
>> The difference between B_text1 and B_text2 is that the end differ in this
>> way:
>>
>> B_text1 --> B_par_text1.end;bt_A.activateEvent
>> B_text2 --> B_par_text1.end;B_par.end
>>
>> BUT, since B_par group has the end attribute set to: bt_A.activateEvent,
>> shouldn't B_par.end and bt_A.activateEvent act the SAME way?

It seems to me you've uncovered a bug in the RealPlayer.  When you click
on bt_A, since B_par has an end="bt_A.activateEvent", it ends.  It
doesn't matter what's inside, but all that is inside should end then as
well, so this definitely includes B_text1 and B_text2.  There is no two
ways about it, and it doesn't matter what their end attributes say, they
should end.

-- 
Sjoerd Mullender
Received on Sunday, 17 June 2007 10:40:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:53:29 GMT