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

Re: R: R: Urgent please

From: Sjoerd Mullender <sjoerd@acm.org>
Date: Mon, 18 Jun 2007 06:44:21 +0000
Message-ID: <467629C5.9060401@acm.org>
To: ___ <berlusconigay@gmail.com>
CC: "'Jack Jansen'" <Jack.Jansen@cwi.nl>, "'SMIL List'" <www-smil@w3.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


Received on Monday, 18 June 2007 06:44:36 GMT

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