<div dir="ltr"><div>Joe,</div><div><br></div><div>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:</div><div><br></div><a href="https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Browser/X3DBrowser.js#L606" target="_blank">https://github.com/create3000/<wbr>cobweb/blob/master/cobweb.js/<wbr>cobweb/Browser/X3DBrowser.js#<wbr>L606</a>  <br><div><br></div><div>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.</div><div><br></div><div>The basic flow for cobweb and cobweb_dom into the x3d browser is, (using Background as example):</div><div><br></div><div>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</div><div><br></div><div>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.</div><div><br></div><div>For x3dom I am less sure but it would be possible to find out:</div><div><br></div><div>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.<br></div><div><br></div><div>So quite similar, just no explicit use of x3d events, more like directOutput for x3d scripts.</div><div><br></div><div>-Andreas</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 16, 2016 at 1:15 PM, Joe D Williams <span dir="ltr"><<a href="mailto:joedwil@earthlink.net" target="_blank">joedwil@earthlink.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This is similar to events caused by external SAI actions which happen when<br>
they happen. The SAI spec. says somewhere that those SAI events need to<br>
trigger a fresh cascade. cobweb_dom and cobweb may currently sort such<br>
events into the event stream of the current cascade (or perhaps next<br>
scheduled cascade) as is being described for asynchronous scripts but I am<br>
not sure.<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks Again,<br>
Joe<br>
<br>
<br>
<br>
----- Original Message ----- From: "Andreas Plesch" <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
To: "Don Brutzman" <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
Cc: "X3D Graphics public mailing list" <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
Sent: Thursday, November 03, 2016 1:18 PM<br>
Subject: Re: [x3d-public] event tracing<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Thu, Nov 3, 2016 at 12:45 PM, Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Very interesting.  Wondering, do you think this might lead to violations<br>
of the loop-breaking rule for events?<br>
<br>
</blockquote>
<br>
Not quite sure what you may refer to. The logging is just logging, nothing<br>
else. When I mentioned seemingly variable processing times for the same<br>
event, I was referring to the same event repeated in different cascades<br>
(x3d timestamps).<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Essentially, the rule says that all event values generated during a given<br>
event cascade (i.e. between frame draws) are checked.  If two events are<br>
both produced by the same source into the same ROUTE, then duplication<br>
(likely a loop) has occurred.  Such recurrences are dropped to avoid<br>
infinite loops.<br>
<br>
I've always assumed that this means the duplicate events have the same<br>
timestamp, thinking for typical implementations that is probably what<br>
occurs.<br>
<br>
However, if the check is performed by each individual ROUTE, which can<br>
tell if a redraw has occurred since last receiving an eventOut value,<br>
perhaps strict comparison of timestamp values isn't necessary?<br>
<br>
</blockquote>
<br>
not sure.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Key references:<br>
...<br>
<br>
29.2.7 Asynchronous scripts<br>
<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/</a><br>
Part01/components/<a href="http://scripting.ht">scripting.ht</a><wbr>ml#Asynchronousscripts<br>
<br>
"Some languages supported by X3D browsers may allow Script nodes to<br>
spontaneously generate events, allowing users to create Script nodes that<br>
function like new X3DSensorNode nodes. In these cases, the Script is<br>
generating the initial events that causes the event cascade, and the<br>
scripting language and/or the browser shall determine an appropriate<br>
timestamp for that initial event. Such events are then sorted into the<br>
event stream and processed like any other event, following all of the same<br>
rules including those for looping."<br>
<br>
</blockquote>
<br>
This is similar to events caused by external SAI actions which happen when<br>
they happen. The SAI spec. says somewhere that those SAI events need to<br>
trigger a fresh cascade. cobweb_dom and cobweb may currently sort such<br>
events into the event stream of the current cascade (or perhaps next<br>
scheduled cascade) as is being described for asynchronous scripts but I am<br>
not sure.<br>
<br>
One could start to think about testing a loop producing (malicious) ROUTE<br>
or script. The loop could be produced just internally and also somehow by<br>
involving the DOM integration (but any DOM action caused by a x3d event of<br>
the current cascade should always affect/trigger a later cascade). Is<br>
there a loop example somewhere ?<br>
<br>
-Andreas<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
==============================<wbr>=============<br>
<br>
On 11/3/2016 6:32 AM, Andreas Plesch wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Mon, Oct 31, 2016 at 6:54 PM, Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a> <mailto:<br>
<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>>> wrote:<br>
<br>
    Tres cool, thank you for this information Andreas.<br>
<br>
    Trace performance of your teapot widgets is absolutely tremendous,<br>
even while printing trace values on the screen (historically a bog on<br>
performance).  No discernible change in perceived responsiveness,<br>
with/without firebug tracing, even when i interactively try to provoke<br>
sluggishness (running good old Windows 7 firefox).<br>
<br>
<br>
I slightly updated the event logging to use performance.now rather than<br>
event.timeStamp which is consistent across browsers and to also report the<br>
difference between the x3d timestamp and the time of logging which should<br>
happen just after dispatching of the DOM event and before drawing to the<br>
webgl canvas. The x3d timestamp is created at the beginning of processing<br>
of x3d events for each cascade, I believe. This difference varies<br>
considerably, about between 2 ms and 20 ms, even for repeats of the same<br>
events. Chrome shows a little less difference on average. So I am not sure<br>
how accurate these timings are in relation to when things really happen and<br>
what external factors influence these.<br>
<br>
<a href="https://andreasplesch.github.io/cobweb_dom/tests/interactive" rel="noreferrer" target="_blank">https://andreasplesch.github.i<wbr>o/cobweb_dom/tests/interactive</a><br>
Transformations.xhtml<br>
<br>
-Andreas<br>
<br>
</blockquote>
<br>
<br>
all the best, Don<br>
--<br>
Don Brutzman  Naval Postgraduate School, Code USW/Br<br>
<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA<br>
<a href="tel:%2B1.831.656.2149" value="+18316562149" target="_blank">+1.831.656.2149</a><br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzma" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzma</a><br>
n<br>
<br>
</blockquote>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
39 Barbara Rd.<br>
Waltham, MA 02453<br>
<br>
</blockquote>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>--------------------<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
______________________________<wbr>_________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listi<wbr>nfo/x3d-public_web3d.org</a><br>
<br>
</blockquote>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>