[x3d-public] event tracing

Wed Nov 16 10:15:17 PST 2016

> 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.

Maybe old and settled, but the way I have seen #X3D work is that an 
event from 'external' source is gated by the beginUpdate();  and 
endUpdate(); 'external' SAI functions. Unless you declare 
beginUpdate(); events are accepted and converted to 'internal' events' 
at the the X3D browser convenience. If you declare beginUpdate(); any 
'external' SAI events are buffered then, when the endUpdate(); is 
received the buffered events have the same time stamp and are 
processed as 'internal' events.

So far, when using DOM events to control the <x3d> beginUPdate and 
endUpdate are not mentioned, that I have seen, even when scripting an 
Inline from the DOM.

Thanks Again,
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 1: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
> 