[x3d-public] event tracing

Andreas Plesch andreasplesch at gmail.com
Wed Nov 16 11:30:01 PST 2016


Joe,

thanks for bringing up .begin/endUpdate(); . I understood it more like an
optional mechanism for bundling (input) events into batches which can then
be processed by the x3d browser in a single cascade and perhaps therefore
more efficiently. I thought about using it for cobweb_dom to collect the
potentially multiple mutations observed by the DOM mutation observer into a
single batch since cobweb seems to have those SAI functions:

https://github.com/create3000/cobweb/blob/master/cobweb.js/
cobweb/Browser/X3DBrowser.js#L606

At first glance, however, the code looks more like enable/disable any
updates, so I am not sure if it would work. These functions do not seem to
be used internally by cobweb.

The basic flow for cobweb and cobweb_dom into the x3d browser is, (using
Background as example):

BackgroundElementDomObject.setAttribute('skyColor','0 0 1') -> mutation
observer: 'look, a mutation, let's do something' -> cobweb_dom: find x3d
node and field corresponding to BackgroundElement and skyColor -> parse '0
0 1' into SFColor -> send input event to x3d browser (cobweb) using
.addEvent() -> cobweb just treats it as an internal event, so I do not
think it triggers a new cascade unless there is none -> cascade -> picked
up at next traversal for new frame

With beginUpdate() cobweb should buffer all received events until
endUpdate() and then dispatch them in the order received I believe. Not
sure if there is such a buffer. It looks more like all event after
endUpdate() are ignored and evaporate but I may be wrong.

For x3dom I am less sure but it would be possible to find out:

BackgroundElementDomObject.setAttribute('skyColor','0 0 1') -> mutation
event (similar to mutation observer but deprecated) handler directly to (no
events) -> x3domBackgroundNode.fieldChanged(), change value of field
including parsing -> routing somehow, either now cascade-like or at next
traversal -> change picked up at next traversal for new frame.

So quite similar, just no explicit use of x3d events, more like
directOutput for x3d scripts.

-Andreas


On Wed, Nov 16, 2016 at 1:15 PM, Joe D Williams <joedwil at earthlink.net>
wrote:

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


-- 
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/20161116/b8423de1/attachment-0001.html>


More information about the x3d-public mailing list