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

Re: Urgent please

From: Jack Jansen <Jack.Jansen@cwi.nl>
Date: Sun, 17 Jun 2007 00:47:52 +0200
Message-Id: <419F0B3A-F658-4A0A-A61D-CC3C8A3AEC71@cwi.nl>
Cc: "'SMIL List'" <www-smil@w3.org>
To: ___ <berlusconigay@gmail.com>
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?

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?
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.472 / Virus Database: 269.8.17/850 - Release Date:  
> 15/06/2007
> 11.31
>
>
>

--
Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman





Received on Saturday, 16 June 2007 22:48:09 GMT

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