<div dir="ltr">Hi Don,<div><br></div><div>I took a stab at amending the execution model figure you referred to (<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>) with some boxes and arrows to visualize conceptual event flow between the DOM and the X3D browser.</div><div><br></div><div><a href="https://docs.google.com/drawings/d/1lfBz686JbCzntBnSM5449oocTrmEIDa8hEyYGTEqW_s/edit?usp=sharing">https://docs.google.com/drawings/d/1lfBz686JbCzntBnSM5449oocTrmEIDa8hEyYGTEqW_s/edit?usp=sharing</a><br></div><div><br></div><div>I made the drawing editable to everyone and would welcome any revisions, redesigns or refinements. This is just a straw man.</div><div><br></div><div>For example, there could be an arrow from input events into the DOM (similar to the one for output events). There could also be an arrow from the scene-graph into DOM to symbolize synchronization of internal changes to the scene-graph with the DOM node tree.</div><div><br></div><div>Also, the spec. Execution Model section mentions the SAI but it is not shown in the original figure.<br></div><div><br></div><div>Andreas</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 31, 2016 at 6:34 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">On 10/31/2016 2:43 PM, Andreas Plesch wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is what I found:<br>
[...]<br>
It was good for me to get a sense of how cobweb works anyways. Perhaps it is helpful in general,<br>
</blockquote>
<br>
Yes thanks.  8)<br>
<br>
Here is a functional description from the X3D abstract specification, along with a generic figure for X3D players.<br>
<br>
==============================<wbr>==============================<wbr>==============================<wbr>====<br>
4.4.8.3 Execution model<br>
<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#ExecutionModel" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/<wbr>Part01/concepts.html#<wbr>ExecutionModel</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Once a sensor or Script has generated an initial event, the event is propagated from the field producing the event along any ROUTEs to other nodes. These other nodes may respond by generating additional events, continuing until all routes have been honoured. This process is called an event cascade. All events generated during a given event cascade are assigned the same timestamp as the initial event, since all are considered to happen instantaneously.<br>
<br>
Some sensors generate multiple events simultaneously. Similarly, it is possible that asynchronously generated events could arrive at the identical time as one or more sensor generated event. In these cases, all events generated are part of the same initial event cascade and each event has the same timestamp. The order in which the events are applied is not considered significant. Conforming X3D worlds shall be able to accommodate simultaneous events in arbitrary order.<br>
<br>
After all events of the initial event cascade are honored, post-event processing performs actions stimulated by the event cascade. The browser shall perform the following sequence of actions during a single timestamp:<br>
<br>
    Update camera based on currently bound Viewpoint's position and orientation.<br>
    Evaluate input from sensors.<br>
    Evalute routes.<br>
    If any events were generated from steps b and c, go to step b and continue.<br>
    If particle system evaluation is to take place, evaluate the particle systems here.<br>
    If physics model evaluation is to take place, evaluate the physics model.<br>
<br>
For profiles that support Script nodes and the Scene Access Interface, the above order may have several intermediate steps. Details are described in 29 Scripting and 2[I.19775-2].<br>
<br>
Figure 4.3 provides a conceptual illustration of the execution model.<br>
<br>
Conceptual execution model<br>
<br>
Figure 4.3 — Conceptual execution model<br>
</blockquote>
<br>
        <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Images/ConceptualExecutionModel.png" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/<wbr>Images/ConceptualExecutionMode<wbr>l.png</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nodes that contain output events shall produce at most one event per field per timestamp. If a field is connected to another field via a ROUTE, an implementation shall send only one event per ROUTE per timestamp. This also applies to scripts where the rules for determining the appropriate action for sending output events are defined in 29 Scripting component.<br>
</blockquote>
==============================<wbr>==============================<wbr>==============================<wbr>====<br>
<br>
<br>
Meanwhile, looking at HTML5 and HTML5.1<br>
<br>
10 Rendering<br>
<a href="https://www.w3.org/TR/html5/rendering.html#rendering" rel="noreferrer" target="_blank">https://www.w3.org/TR/html5/re<wbr>ndering.html#rendering</a><br>
<br>
10. Rendering<br>
<a href="https://www.w3.org/TR/html51/rendering.html#rendering" rel="noreferrer" target="_blank">https://www.w3.org/TR/html51/r<wbr>endering.html#rendering</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
User agents are not required to present HTML documents in any particular way. However, this section provides a set of suggestions for rendering HTML documents that, if followed, are likely to lead to a user experience that closely resembles the experience intended by the documents' authors.<br>
</blockquote>
<br>
[plus spec-wonk legalese]<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 So as to avoid confusion regarding the normativity of this section, RFC2119 terms have not been used. Instead, the term "expected" is used to indicate behavior that will lead to this experience. For the purposes of conformance for user agents designated as supporting the suggested default rendering, the term "expected" in this section has the same conformance implications as the RFC2119-defined term "must".<br>
</blockquote>
<br>
and looking at the Document Object Model (DOM) used by HTML5/5.1:<br>
<br>
W3C DOM4; W3C Recommendation 19 November 2015<br>
<a href="https://www.w3.org/TR/dom/" rel="noreferrer" target="_blank">https://www.w3.org/TR/dom/</a><br>
<br>
3 Events<br>
3.1 Introduction to "DOM Events"<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Throughout the web platform events are dispatched to objects to signal an occurrence, such as network activity or user interaction.<br>
</blockquote>
<br>
Numerous functionality descriptions for DOM event passing are found there.  But: no timing or sequence diagrams found there.  Has anyone seen "render loop" diagrams for HTML anywhere else?<br>
<br>
Clarity challenge: it would be quite interesting to come up with figure or two that *illustrates DOM events interacting with X3D events and rendering a shared web page.*<br>
<br>
Meanwhile again... rendering at 60fps stereo or better is certainly a wonderful goal. More is better.  Perception of smooth motion occurs at 7-8 Hz, framerates above 15fps are hard to distinguish... whatever works.  However I've seen nothing published that indicates whether such performance actually avoids the the physiological and psychological triggers causing simulator sickness.<br>
<br>
In general, the event loop for DOM can be connected yet decoupled from the event loop for X3D.  Such as situation exists already in the X3D architecture and Scene Access Interface (SAI) design that allows both internal-within-scene-graph and external-in-HTML-browser scripting and event passing.<br>
<br>
Rephrase, answering Mike's related concerns regarding frame rate: parallelization allows each to proceed at their own pace, carefully deliberate event exchange allows each to stay loosely synchronized.  Our current Javascript-based X3D players take advantage of the same optimizations of the same features being optimized for WebGL programs.  Thus X3D player performance can float right along and utilize the same browser performance-improvement advantages being pursued by everyone else.  Thus headset motion-sensitive rendering performance can be decoupled from web-browser user interactions, for HTML5 Canvas or for X3D.<br>
<br>
Definitely worth continued study, illustration with diagrams, confirmation with implementations, and (likely) description inclusion in future X3D v4 specification.<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>