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  

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  

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:26 UTC