- From: Sjoerd Mullender <sjoerd@acm.org>
- Date: Mon, 18 Jun 2007 06:44:21 +0000
- To: ___ <berlusconigay@gmail.com>
- CC: "'Jack Jansen'" <Jack.Jansen@cwi.nl>, "'SMIL List'" <www-smil@w3.org>
- Message-ID: <467629C5.9060401@acm.org>
___ wrote: >> Please explain how a bug in one implementation of SMIL makes SMIL totally > useless? > > Yes sorry, that was frustration, it doesn't mean nothing. > >> Have you tried other players, e.g. ambulant or GRiNS? > > I tried ambulant but it has problems to show static gif or png images, so > even pages that works on realplayer doesn't work there :( Grins player is > not freeware or evaluation edition, so i couldn't had a chance to try it > >> The first version below is a copy of your version with all superfluous > attributes removed. > > And it doesn't work. I arrived to this version since excl didn't work, i > know it's a bad way of code it... > >> The second is an equivalent version that uses excl > > That's a sort of what i tried in first instance (your version is clearer) > but unfortunately it doesn't work. > I uploaded the presentation on rapidshare, so if maybe you want to try it, > you could check if it's a realplayer bug (so i can notice them or something > like that) or it's me that is doing something wrong.. > http://rapidshare.com/files/37735652/bug.rar.html > Index.smil works good since there are only some animation, while storia.smil > is the bugged one, clicking on second menu link and then the first one, will > show images of both links, instead of removing them =\ > > Hope you have some time to test it and let me know if i should report to > RealPlayer (in some way) the bug. > Thanks in advance The attached seems to work. What I did was simplify the code more. I removed all the z-index manipulation, but instead did the overlays in the excl's. Looks ok in the RealPlayer. > > -----Messaggio originale----- > Da: Sjoerd Mullender [mailto:sjoerd@acm.org] > Inviato: domenica 17 giugno 2007 14.03 > A: ___ > Cc: 'Jack Jansen'; 'SMIL List' > Oggetto: Re: R: Urgent please > > On 06/17/2007 01:04 PM, ___ wrote: >> Well, if realplayer can't handle it, then SMIL is totally useless. I >> mean, > > Please explain how a bug in one implementation of SMIL makes SMIL totally > useless? > Have you tried other players, e.g. ambulant or GRiNS? > >> if it handle just the base things like transitions of slides, then i >> could use powerpoint for a presentation. The nice thing of SMIL should >> be the interactivity. After 2 weeks i couldn't handle succesfully to >> load on same page objects according to what is selected from menu. Use >> href to link to external .smil files is terrible and senseless, but >> seems the only thing that works. >> I would expect to use <excl> group and fix things: no! It just doesn't >> work, i understood that only the begin event should be described for >> each excl child and excl will handle to exclusively load the child >> group. Obviously that doesn't work, and objects from other excl >> children are still visible for no reason (no, i didn't use the >> fill="hold"). I tried several tutorial with excl, but only those that >> load just an image per child works.. If i start from those and add >> groups as excl child, then all mess up, sooner or late. >> Is there any template that works on realplayer or any other player >> where SMIL has sense and interactive presentation works? >> Please answer, since i'm quite frustrated > > I'm not really getting a warm, fuzzy feeling from trying to help you. > > There are a few things you could try to get those textstreams to end when > you click on the button, but first I would try to *simplify* the code by > removing begin/end attribute values that are already implied by the timing > model. The first version below is a copy of your version with all > superfluous attributes removed. The second is an equivalent version that > uses excl. The second version would be the preferred way of doing it. I > think they should both do what you seem to want, but I cannot guarantee that > the RealPlayer does this correctly. If it doesn't, then it's a bug in the > RealPlayer, not in SMIL. Don't confuse the two. > > <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="arrow_f.activateEvent"> > <textstream id="B_text1" src="..." rn:backgroundOpacity="0%" > transIn="fade_1" region="text_B_a" fill="freeze"/> > <textstream id="B_text2" src="..." rn:backgroundOpacity="0%" > transIn="fade_1" region="text_B_b" fill="freeze"/> > </par> > <par id="B_par_text2" begin="arrow_f.activateEvent" > end="arrow_b.activateEvent"> > ....... > </par> > </par> > </par> > </body> > > <body> > <excl dur="indefinite"> > <par id="A_par" begin="bt_A.activateEvent"> > ...... > </par> > <excl id="B_par" begin="bt_B.activateEvent"> > <par id="B_par_text1" begin="0s;arrow_b.activateEvent"> > <textstream id="B_text1" src="..." rn:backgroundOpacity="0%" > transIn="fade_1" region="text_B_a" fill="freeze"/> > <textstream id="B_text2" src="..." rn:backgroundOpacity="0%" > transIn="fade_1" region="text_B_b" fill="freeze"/> > </par> > <par id="B_par_text2" begin="arrow_f.activateEvent"> > ....... > </par> > </par> > </par> > </body> > > >> -----Messaggio originale----- >> Da: Sjoerd Mullender [mailto:sjoerd@acm.org] >> Inviato: domenica 17 giugno 2007 12.40 >> A: Jack Jansen >> Cc: ___; 'SMIL List' >> Oggetto: Re: Urgent please >> >> 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 >> >> 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 >> >> >> > > > -- > Sjoerd Mullender > > 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 > > -- Sjoerd Mullender
Attachments
- application/smil attachment: storia.smil
Received on Monday, 18 June 2007 06:44:36 UTC