[x3d-public] event tracing

[Joe D Williams]

>> Very interesting.  Wondering, do you think this might lead to 
>> violations
>> of the loop-breaking rule for events?

>> However, if the check is performed by each individual ROUTE, which 
>> can
>> tell if a redraw has occurred since last receiving an eventOut 
>> value,
>> perhaps strict comparison of timestamp values isn't necessary?

I think the rules are set up with the idea that there may be more than 
one cascade to build the frame, so the emphasis is on the timestamp of 
a group of events. That allow multiple cascades with possible, 
multiple events on the same nodes, thus the same route.

So, all that has to be done is keep track of the last timestamp and 
not allow propagation if the timestamp is the same. The redraw time is 
not the issue.

The main issue happens when any cascade is interrupted due to forcing 
a redraw with an incomplete cascade. True, most of the time this is 
not important until you need to call yor model an authored simulation. 
If the author cannot count on the cascade in timestampled rendering of 
a delicate simulation frame, then it is just a frame of a realtime 
scene, not a true frame of a delicate simulaltion.

I think scripts that emit initial events (original directOut) can be 
built to not use routes and so are not in the cascade, but the node 
that receives the event may generate an output which, if routed, would 
be the first event of that cascade.

Thanks,
Joe









----- Original Message ----- 
From: "Andreas Plesch" <andreasplesch at gmail.com>
To: "Don Brutzman" <brutzman at nps.edu>
Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>
Sent: Thursday, November 03, 2016 2:18 PM
Subject: Re: [x3d-public] event tracing


> On Thu, Nov 3, 2016 at 12:45 PM, Don Brutzman <brutzman at nps.edu> 
> wrote:
>
>> Very interesting.  Wondering, do you think this might lead to 
>> violations
>> of the loop-breaking rule for events?
>>
>
> Not quite sure what you may refer to. The logging is just logging, 
> nothing
> else. When I mentioned seemingly variable processing times for the 
> same
> event, I was referring to the same event repeated in different 
> cascades
> (x3d timestamps).
>
>
>> Essentially, the rule says that all event values generated during a 
>> given
>> event cascade (i.e. between frame draws) are checked.  If two 
>> events are
>> both produced by the same source into the same ROUTE, then 
>> duplication
>> (likely a loop) has occurred.  Such recurrences are dropped to 
>> avoid
>> infinite loops.
>>
>> I've always assumed that this means the duplicate events have the 
>> same
>> timestamp, thinking for typical implementations that is probably 
>> what
>> occurs.
>>
>> However, if the check is performed by each individual ROUTE, which 
>> can
>> tell if a redraw has occurred since last receiving an eventOut 
>> value,
>> perhaps strict comparison of timestamp values isn't necessary?
>>
>
> not sure.
>
>
>> Key references:
>> ...
>>
>> 29.2.7 Asynchronous scripts
>> http://www.web3d.org/documents/specifications/19775-1/V3.3/
>> Part01/components/scripting.html#Asynchronousscripts
>>
>> "Some languages supported by X3D browsers may allow Script nodes to
>> spontaneously generate events, allowing users to create Script 
>> nodes that
>> function like new X3DSensorNode nodes. In these cases, the Script 
>> is
>> generating the initial events that causes the event cascade, and 
>> the
>> scripting language and/or the browser shall determine an 
>> appropriate
>> timestamp for that initial event. Such events are then sorted into 
>> the
>> event stream and processed like any other event, following all of 
>> the same
>> rules including those for looping."
>>
>
> This is similar to events caused by external SAI actions which 
> happen when
> they happen. The SAI spec. says somewhere that those SAI events need 
> to
> trigger a fresh cascade. cobweb_dom and cobweb may currently sort 
> such
> events into the event stream of the current cascade (or perhaps next
> scheduled cascade) as is being described for asynchronous scripts 
> but I am
> not sure.
>
> One could start to think about testing a loop producing (malicious) 
> ROUTE
> or script. The loop could be produced just internally and also 
> somehow by
> involving the DOM integration (but any DOM action caused by a x3d 
> event of
> the current cascade should always affect/trigger a later cascade). 
> Is
> there a loop example somewhere ?
>
> -Andreas
>
>
>
>> ===========================================
>>
>> On 11/3/2016 6:32 AM, Andreas Plesch wrote:
>>
>>> On Mon, Oct 31, 2016 at 6:54 PM, Don Brutzman <brutzman at nps.edu 
>>> <mailto:
>>> brutzman at nps.edu>> wrote:
>>>
>>>     Tres cool, thank you for this information Andreas.
>>>
>>>     Trace performance of your teapot widgets is absolutely 
>>> tremendous,
>>> even while printing trace values on the screen (historically a bog 
>>> on
>>> performance).  No discernible change in perceived responsiveness,
>>> with/without firebug tracing, even when i interactively try to 
>>> provoke
>>> sluggishness (running good old Windows 7 firefox).
>>>
>>>
>>> I slightly updated the event logging to use performance.now rather 
>>> than
>>> event.timeStamp which is consistent across browsers and to also 
>>> report the
>>> difference between the x3d timestamp and the time of logging which 
>>> should
>>> happen just after dispatching of the DOM event and before drawing 
>>> to the
>>> webgl canvas. The x3d timestamp is created at the beginning of 
>>> processing
>>> of x3d events for each cascade, I believe. This difference varies
>>> considerably, about between 2 ms and 20 ms, even for repeats of 
>>> the same
>>> events. Chrome shows a little less difference on average. So I am 
>>> not sure
>>> how accurate these timings are in relation to when things really 
>>> happen and
>>> what external factors influence these.
>>>
>>> https://andreasplesch.github.io/cobweb_dom/tests/interactive
>>> Transformations.xhtml
>>>
>>> -Andreas
>>>
>>
>>
>> all the best, Don
>> --
>> Don Brutzman  Naval Postgraduate School, Code USW/Br
>> brutzman at nps.edu
>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>> +1.831.656.2149
>> X3D graphics, virtual worlds, navy robotics 
>> http://faculty.nps.edu/brutzma
>> n
>>
>
>
>
> -- 
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>


--------------------------------------------------------------------------------


> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>