<p dir="ltr">On Nov 17, 2016 3:11 PM, "Joe D Williams" <<a href="mailto:joedwil@earthlink.net">joedwil@earthlink.net</a>> wrote:<br>
><br>
> <a href="http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#UpdateControl">http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#UpdateControl</a><br>
><br>
> ...<br>
> I am sure that is the intent of the SAI design. There are in fact some rules, like I think I remember that the external is not allowed to send MF items one at a time, it must be the complete field(?). Mainly that the X3D processing model may take some time to make the current frame. During that time, she mostly may not care about most classes of events. The she wakes up again and asks what time it is and what has happened and what wants to happen since she went to sleep to make the current frame.<br>
></p>
<p dir="ltr">I like that kind of description of the processing model.</p>
<p dir="ltr">>> These functions do not seem to<br>
>> be used internally by cobweb.<br>
><br>
><br>
> Internally, the default must be to somehow accumulate events until it is ready to work on the next frame.</p>
<p dir="ltr">Yes, I needed to understand better how that happens in Cobweb but I am sure that it does.</p>
<p dir="ltr">> This meeting of X3D and DOM is very interesting. It is very easy for an author to flog the x3d internal processing model from the inside and from the outside.</p>
<p dir="ltr">That may be the main challenge, that external control becomes more important to the author than internal control.</p>
<p dir="ltr"> What is the desired <x3d> 'internal' processing model? Is it different than the 'internal processing model described in the X3D spec. </p>
<p dir="ltr">Good questions. The goal is to keep the internal processing model intact.</p>
<p dir="ltr">How does the <x3d> in html 'internal' processing model line up with<br>
><br>
> <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#ExecutionModel">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#ExecutionModel</a><br>
><br>
> In the diagram, you described processing flows between functionalities. Do we need to define what is actually going on internally to show sequence of what is happening to produce the <x3d> scene? I think yes.</p>
<p dir="ltr">The internal sequencing shown is straight from the current spec. </p>
<p dir="ltr">> The "post-event processing" seems real important to understand. Not sure how this works with the 'external' DOM and scene processing run from an 'internal' model complsed by a set of scripts. Is there some "pre-event processing" that takes place, and maybe some post-post-processing?</p>
<p dir="ltr">This is hard to follow. A concrete example may help ?</p>
<p dir="ltr">Andreas </p>
<p dir="ltr">><br>
> abstract<br>
> <a href="http://www.hypermultimedia.com/x3d/Quick/SAIABSDEFS.htm">http://www.hypermultimedia.com/x3d/Quick/SAIABSDEFS.htm</a><br>
> ecma<br>
> <a href="http://www.hypermultimedia.com/x3d/Quick/SAIDEFS.htm">http://www.hypermultimedia.com/x3d/Quick/SAIDEFS.htm</a><br>
><br>
><br>
><br>
><br>
><br>
> ----- Original Message ----- From: "Andreas Plesch" <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>><br>
> To: "Joe D Williams" <<a href="mailto:joedwil@earthlink.net">joedwil@earthlink.net</a>><br>
> Cc: "Don Brutzman" <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>>; "X3D Graphics public mailing list" <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
> Sent: Wednesday, November 16, 2016 11:30 AM<br>
><br>
> Subject: Re: [x3d-public] event tracing<br>
><br>
><br>
>> Joe,<br>
>><br>
>> thanks for bringing up .begin/endUpdate(); . I understood it more like an<br>
>> optional mechanism for bundling (input) events into batches which can then<br>
>> be processed by the x3d browser in a single cascade and perhaps therefore<br>
>> more efficiently. I thought about using it for cobweb_dom to collect the<br>
>> potentially multiple mutations observed by the DOM mutation observer into a<br>
>> single batch since cobweb seems to have those SAI functions:<br>
>><br>
>> <a href="https://github.com/create3000/cobweb/blob/master/cobweb.js/">https://github.com/create3000/cobweb/blob/master/cobweb.js/</a><br>
>> cobweb/Browser/X3DBrowser.js#L606<br>
>><br>
>> At first glance, however, the code looks more like enable/disable any<br>
>> updates, so I am not sure if it would work. These functions do not seem to<br>
>> be used internally by cobweb.<br>
>><br>
>> The basic flow for cobweb and cobweb_dom into the x3d browser is, (using<br>
>> Background as example):<br>
>><br>
>> BackgroundElementDomObject.setAttribute('skyColor','0 0 1') -> mutation<br>
>> observer: 'look, a mutation, let's do something' -> cobweb_dom: find x3d<br>
>> node and field corresponding to BackgroundElement and skyColor -> parse '0<br>
>> 0 1' into SFColor -> send input event to x3d browser (cobweb) using<br>
>> .addEvent() -> cobweb just treats it as an internal event, so I do not<br>
>> think it triggers a new cascade unless there is none -> cascade -> picked<br>
>> up at next traversal for new frame<br>
>><br>
>> With beginUpdate() cobweb should buffer all received events until<br>
>> endUpdate() and then dispatch them in the order received I believe. Not<br>
>> sure if there is such a buffer. It looks more like all event after<br>
>> endUpdate() are ignored and evaporate but I may be wrong.<br>
>><br>
>> For x3dom I am less sure but it would be possible to find out:<br>
>><br>
>> BackgroundElementDomObject.setAttribute('skyColor','0 0 1') -> mutation<br>
>> event (similar to mutation observer but deprecated) handler directly to (no<br>
>> events) -> x3domBackgroundNode.fieldChanged(), change value of field<br>
>> including parsing -> routing somehow, either now cascade-like or at next<br>
>> traversal -> change picked up at next traversal for new frame.<br>
>><br>
>> So quite similar, just no explicit use of x3d events, more like<br>
>> directOutput for x3d scripts.<br>
>><br>
>> -Andreas<br>
>><br>
>><br>
>> On Wed, Nov 16, 2016 at 1:15 PM, Joe D Williams <<a href="mailto:joedwil@earthlink.net">joedwil@earthlink.net</a>><br>
>> wrote:<br>
>><br>
>>> This is similar to events caused by external SAI actions which happen when<br>
>>>><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>
>>><br>
>>> Maybe old and settled, but the way I have seen #X3D work is that an event<br>
>>> from 'external' source is gated by the beginUpdate(); and endUpdate();<br>
>>> 'external' SAI functions. Unless you declare beginUpdate(); events are<br>
>>> accepted and converted to 'internal' events' at the the X3D browser<br>
>>> convenience. If you declare beginUpdate(); any 'external' SAI events are<br>
>>> buffered then, when the endUpdate(); is received the buffered events have<br>
>>> the same time stamp and are processed as 'internal' events.<br>
>>><br>
>>> So far, when using DOM events to control the <x3d> beginUPdate and<br>
>>> endUpdate are not mentioned, that I have seen, even when scripting an<br>
>>> Inline from the DOM.<br>
>>><br>
>>> Thanks Again,<br>
>>> Joe<br>
>>><br>
>>><br>
>>><br>
>>> ----- Original Message ----- From: "Andreas Plesch" <<br>
>>> <a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>><br>
>>> To: "Don Brutzman" <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>><br>
>>> Cc: "X3D Graphics public mailing list" <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
>>> Sent: Thursday, November 03, 2016 1:18 PM<br>
>>> Subject: Re: [x3d-public] event tracing<br>
>>><br>
>>><br>
>>> On Thu, Nov 3, 2016 at 12:45 PM, Don Brutzman <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>> wrote:<br>
>>>><br>
>>>><br>
>>>> Very interesting. Wondering, do you think this might lead to violations<br>
>>>>><br>
>>>>> of the loop-breaking rule for events?<br>
>>>>><br>
>>>>><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>
>>>> Essentially, the rule says that all event values generated during a given<br>
>>>>><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>
>>>>><br>
>>>> not sure.<br>
>>>><br>
>>>><br>
>>>> Key references:<br>
>>>>><br>
>>>>> ...<br>
>>>>><br>
>>>>> 29.2.7 Asynchronous scripts<br>
>>>>> <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/">http://www.web3d.org/documents/specifications/19775-1/V3.3/</a><br>
>>>>> Part01/components/scripting.html#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<br>
>>>>> same<br>
>>>>> rules including those for looping."<br>
>>>>><br>
>>>>><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>
>>>> ===========================================<br>
>>>>><br>
>>>>><br>
>>>>> On 11/3/2016 6:32 AM, Andreas Plesch wrote:<br>
>>>>><br>
>>>>> On Mon, Oct 31, 2016 at 6:54 PM, Don Brutzman <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a> <mailto:<br>
>>>>>><br>
>>>>>> <a href="mailto:brutzman@nps.edu">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<br>
>>>>>> the<br>
>>>>>> difference between the x3d timestamp and the time of logging which<br>
>>>>>> 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<br>
>>>>>> 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<br>
>>>>>> sure<br>
>>>>>> how accurate these timings are in relation to when things really happen<br>
>>>>>> and<br>
>>>>>> what external factors influence these.<br>
>>>>>><br>
>>>>>> <a href="https://andreasplesch.github.io/cobweb_dom/tests/interactive">https://andreasplesch.github.io/cobweb_dom/tests/interactive</a><br>
>>>>>> Transformations.xhtml<br>
>>>>>><br>
>>>>>> -Andreas<br>
>>>>>><br>
>>>>>><br>
>>>>><br>
>>>>> all the best, Don<br>
>>>>> --<br>
>>>>> Don Brutzman Naval Postgraduate School, Code USW/Br<br>
>>>>> <a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a><br>
>>>>> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA<br>
>>>>> +1.831.656.2149<br>
>>>>> X3D graphics, virtual worlds, navy robotics<br>
>>>>> <a href="http://faculty.nps.edu/brutzma">http://faculty.nps.edu/brutzma</a><br>
>>>>> n<br>
>>>>><br>
>>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Andreas Plesch<br>
>>>> 39 Barbara Rd.<br>
>>>> Waltham, MA 02453<br>
>>>><br>
>>>><br>
>>><br>
>>> ------------------------------------------------------------<br>
>>> --------------------<br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>>><br>
>>>> x3d-public mailing list<br>
>>>> <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
>>>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>>>><br>
>>>><br>
>>><br>
>><br>
>><br>
>> -- <br>
>> Andreas Plesch<br>
>> 39 Barbara Rd.<br>
>> Waltham, MA 02453<br>
>><br>
></p>