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

R: Urgent please

From: ___ <berlusconigay@gmail.com>
Date: Sun, 17 Jun 2007 13:12:07 +0200
To: "'Jack Jansen'" <Jack.Jansen@cwi.nl>
Cc: "'SMIL List'" <www-smil@w3.org>
Message-ID: <013301c7b0d0$595669b0$152ca8c0@luca56485194f3>

endEvent instead of end just get things worst :(
If you know any template that works with interaction based on menu
selection, please let me know.
I'm so frustrated i'm just trying all possible combination without success. 
Thanks anyway 

-----Messaggio originale-----
Da: Jack Jansen [mailto:Jack.Jansen@cwi.nl] 
Inviato: domenica 17 giugno 2007 0.48
A: ___
Cc: 'SMIL List'
Oggetto: Re: Urgent please

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>, HYPERLINK
"http://www.cwi.nl/~jack"http://www.cwi.nl/~jack

If I can't dance I don't want to be part of your revolution -- Emma Goldman




No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 16/06/2007
12.50
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.9.0/851 - Release Date: 16/06/2007
12.50
 
Received on Sunday, 17 June 2007 11:12:34 GMT

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