<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 3, 2016 at 12:45 PM, Don Brutzman <span dir="ltr"><<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Very interesting. Wondering, do you think this might lead to violations of the loop-breaking rule for events?<br></blockquote><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
I've always assumed that this means the duplicate events have the same timestamp, thinking for typical implementations that is probably what occurs.<br>
<br>
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?<br></blockquote><div><br></div><div>not sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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/Part01/components/scripting.html#Asynchronousscripts" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/<wbr>Part01/components/scripting.<wbr>html#Asynchronousscripts</a><br>
<br>
"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."<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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 ?</div><div><br></div><div>-Andreas</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
==============================<wbr>=============<br>
<br>
On 11/3/2016 6:32 AM, Andreas Plesch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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:<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, 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).<br>
<br>
<br>
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.<br>
<br>
<a href="https://andreasplesch.github.io/cobweb_dom/tests/interactiveTransformations.xhtml" rel="noreferrer" target="_blank">https://andreasplesch.github.i<wbr>o/cobweb_dom/tests/interactive<wbr>Transformations.xhtml</a><br>
<br>
-Andreas<br>
</blockquote>
<br>
<br>
all the best, Don<span class="HOEnZb"><font color="#888888"><br>
-- <br>
Don Brutzman Naval Postgraduate School, Code USW/Br <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA <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/brutzman" rel="noreferrer" target="_blank">http://faculty.nps.edu/brutzma<wbr>n</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>