[x3d-public] [x3d] Goals for V4

Joe D Williams joedwil at earthlink.net
Mon Sep 28 17:14:39 PDT 2015


was: Players that do now observe the cascade rule may leak some series 
of events between frames.

should be:
Players that do NOT observe the cascade rule may leak some of a series 
of linked events between frames.

was: This has always been true and is why VRML and X3D have
timestamp and the concept of the event cascade.

should be:
This has always been true and is why VRML and X3D have timestamp and 
the concept of the event cascade fully included as an important 
authoring and playback aid.

Thanks,
Joe



----- Original Message ----- 
From: "Joe D Williams" <joedwil at earthlink.net>
To: "Roy Walmsley" <roy.walmsley at ntlworld.com>; "'Leonard Daly'" 
<web3d at realism.com>; "'x3D WG'" <x3d at web3d.org>; 
<x3d-public at web3d.org>
Sent: Monday, September 28, 2015 5:10 PM
Subject: Re: [x3d] Goals for V4


>
> ----- Original Message ----- 
>
> Subject: Re: [x3d] Goals for V4
> Len and Roy
>
>
> "As you point out, the event model is one area. "
>
> "out loud I wonder if the current event model in 19775-1 could be
> described as ‘synchronous’. While what we need for HTML5 is an
> ‘asynchronous’ model."
>
> Hi Kids,
>
> The major ideas about the X3D event system is that there exists the
> event cascade and the non-looping rule.
>
> Players that observe the cascade will not allow the new frame to be
> actually rendered until the cascade, or set of linked cascades, is
> complete. This is done by time stamp.
>
> DOM do not due adequate timestamp stuff now, but maybe someday, so 
> for now the X3DOM author will need to rig the cascade hisself if it 
> is important. This has always been true and is why VRML and X3D have
> timestamp and the concept of the event cascade.
>
> This is very important when you are simulating and wish to observe
> exactly which frame an event cascade was completed. Players that do
> now observe the cascade rule may leak some series of events between
> frames.
>
> So, I think ‘synchronous’ must be thought of with respect to 
> completed
> frame, not absolute time. An 'asyncronous' system could leak events
> between frames making animation appear wrong for a frame or two if 
> the
> scenegraph update was ot actually complete. In 'realtime' the next
> frame is produced as soon as it is available and the scenegraph is
> updated, not on a fixed schedule.
>
> The next major issue is the evaluation sequence that happens after 
> the
> current scene is complete and we start preparing for the next. What 
> is
> the order of player considerations to produce the next frame. I the 
> first one to check if the clock has changed since we last checked?
>
> Thanks and Best,
> Joe
>
>
>
> <snip>
>
> --------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> x3d mailing list
>> x3d at web3d.org
>> http://web3d.org/mailman/listinfo/x3d_web3d.org
>>
> 




More information about the x3d-public mailing list