Re: Urgent please
Sjoerd Mullender <[email protected]>
| Newsgroups | gmane.comp.web.smil |
|---|---|
| Message-ID | <[email protected]> |
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