[x3d-public] event tracing

[Andreas Plesch]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161103/45e5e6a3/attachment.html>