<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Not sure how far down the thread to
post a reply, so I'll do it from the top.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">These comments solely have to do with
HTML events and may reference the PDF that Don attached -- the one
that looks like a picture of work on a white board. Since these
comments only address HTML, it is the left side that would be
referenced. I did include Don's comments from the original message
as a reference for X3D. This is kind of long, so I put section
labels to help make it clearer and easier to follow. If there is
enough interest and/or discussion I may write a blog post with
diagrams.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><font size="+1"><b>HTML Events</b></font></div>
<div class="moz-cite-prefix">HTML events are fired in response to
many different conditions. An event is delivered to an event
listener. Listeners must declare which event(s) they are listening
for (e.g., mousedown, mouseup, mousemove, etc.). A listener can
listen for a number of different events, but needs to have the
internal logic to handle them correctly.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><b>Event Listeners</b><br>
</div>
<div class="moz-cite-prefix">A dispatched event contains an object
and a list of functions (listeners) that need to be called. Each
function is called with the event data structure. Additional
processing of the event (after function return) is determine by
event object methods called during the function execution.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The listener is called after the event
is dispatched. The dispatched event goes onto a queue that is
emptied when the JavaScript thread is not processing something
else (JavaScript is single-threaded in all current browser
implementations -- this does not apply to web workers). <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><b>Event Processing</b><br>
</div>
<div class="moz-cite-prefix">When the function completes, control is
returned to the JavaScript engine for additional processing of the
event or a different event. If a listener generates an event, that
event is put at the end of the queue and is not processed until
the main-thread JavaScript code (if any) is run. In a sense, it
can be thought of as processing in the next event cycle. There is
no need to event-loop breaking as there is an automatic break at
the end of each collection of events. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">There is no shuffling of event
processing order. The first event handled by the system goes on
the queue as many times as there are listeners for that event. The
order of the listeners is the order in which they are declared.
Events created by listeners processing an event are put on the
queue for the next event cycle.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><b>Event Practice</b></div>
<div class="moz-cite-prefix">The comment practice is to create
fine-grained events. There are separate events for mouse button
up, down, click, double-click, mouse move, mouse over, etc. Each
event object is light-weight and is mostly (as in I haven't found
any that are not) read-only. Each event has a custom data section
that can be populated when the event object is created prior to
dispatching it. Events are dispatched against almost any
JavaScript object, but especially DOM nodes.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><font size="+1"><b>Animation</b></font><br>
</div>
<div class="moz-cite-prefix">Animation (should) be performed by
calling window.requestAnimationFrame (typically notated as rAF).
This method takes a function as its argument. That function is
called prior to rendering the new/modified content. It must be
called by the function to render the frame after the current one.
All page animations should use method to optimize CPU usage. It
usually runs at the browser refresh rate (typically 60fps), but
stereo headset usage typically strive for 90fps (11
milli-seconds/frame). This applies to CSS, canvas, and all other
rendering that the browser has responsibility.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">It is possible to do so much computing
that the duration between rendered frames is too long for comfort.
Some systems may complain about this. JavaScript developer tools
are very helpful for detecting and debugging these problems.
Generally you should do as little work as possible during an
animation frame cycle. Anything that needs lots of compute cycles
is better handled outside of this thread, perhaps by a web worker.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Events generated during an animation
frame are handled after the frame is rendered and before rAF is
called for the next frame. So it may not be the computations
necessary to render a frame, but event handling that is slowing
down your display. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><font size="+1"><b>Document Comments</b></font></div>
<div class="moz-cite-prefix">This section is my comments against the
PDF. I may be completely wrong in some parts because I did not
participate in the discussion or I am not reading the image
correctly.</div>
<div class="moz-cite-prefix">
<ol>
<li>Events are from all sources, but really amount to DOM
events. There are different kinds of events that reflect all
parts of the web page and browser support for it. MDN has a
partial list at
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en-US/docs/Web/Events">https://developer.mozilla.org/en-US/docs/Web/Events</a></li>
<li>A change to CSS that changes a node state (as opposed to
directly changing a node's attribute value) is also an event
(see
<a class="moz-txt-link-freetext" href="https://developer.mozilla.org/en-US/docs/Web/Events#CSS_Animation_events">https://developer.mozilla.org/en-US/docs/Web/Events#CSS_Animation_events</a>).</li>
<li>User interactions (key strokes, mouse state change (move,
button, etc.) are also DOM events.</li>
<li>Event listeners run as described above in the order
described above.</li>
<li>There is no cascade processing. Events generated by event
listeners are handled on the next event cycle.</li>
<li>Event listeners would be responsible for injecting relevant
information/events into other (e.g., X3DOM) systems</li>
<li>Browser window (or any block element) resize is an event</li>
</ol>
<p>To illustrate event processing, consider the case of a
collision between two objects that you are trying to model. The
collision produces 1,000,000 tiny particles whose motion needs
to be handled. The rAF function gets called to compute the
motion for the next frame of every particle. This takes (for
example) .5 seconds. During that 1/2-second no other JavaScript
code can run. This includes rendering (calls to WebGL), button
handling, etc. After all of the computations are completed and
the frame is rendered, all of the events that were queuing up
are delivered. During that time if there was another collision
with another 1,000,000 particles, those animations would be
processed in the next animation frame along with the original
1,000,000 (assuming the code did not insist on processing the
collisions in separate frames). <br>
</p>
<p>The important thing to remember is event handling is blocking.
Nothing else happens until all queued events are delivered.
Events generated during event handling are in a separate queue
for delivery at the next event cycle.<br>
</p>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Leonard Daly<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<br>
<blockquote type="cite"
cite="mid:a2450931-5645-34fd-0b1d-23c8401a7f94@nps.edu">
<pre class="moz-quote-pre" wrap="">==================================
3. *X3D Architecture Design and Events*
X3Dv4 design review and discussion of documents/diagrams: Web3D 2017/2018 session notes. Highly detailed event-model diagram are found in prior 2017 X3Dv4 architecture presentations.
X3D version 4
<a class="moz-txt-link-freetext" href="http://www.web3d.org/x3d4">http://www.web3d.org/x3d4</a>
X3D Futures: What is happening, how to get involved!
Web3D 2018 Conference, Poznan Poland
<a class="moz-txt-link-freetext" href="http://www.web3d.org/sites/default/files/page/X3D%20Version%204/X3dFuturesWeb3d2018PoznanPolandBrutzman.pdf">http://www.web3d.org/sites/default/files/page/X3D%20Version%204/X3dFuturesWeb3d2018PoznanPolandBrutzman.pdf</a>
"Future of X3D" presentation and detailed notes from Web3D 2017 Conference, Brisbane Australia, 7 June 2017.
<a class="moz-txt-link-freetext" href="http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3D.pdf">http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3D.pdf</a>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3dWeb3d2017June7.pdf">http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3dWeb3d2017June7.pdf</a>
<a class="moz-txt-link-freetext" href="http://www.web3d.org/sites/default/files/image/wg/X3D%20Version%204/PresentationPanoramaFutureOfX3dPaulGrimm20170607_135611.1600x492.jpg">http://www.web3d.org/sites/default/files/image/wg/X3D%20Version%204/PresentationPanoramaFutureOfX3dPaulGrimm20170607_135611.1600x492.jpg</a>
Based on discussions in Korea and preceding documents, Don has written a further-distilled diagram for HTML5/X3D event models (X3Dv4EventDiagram2019January25.pdf attached). Essentially each (HTML5 and X3D) have internal event loops, and natural times to exchange event buffers occur at the each loop. As with current X3D specification, ordering is guaranteed for each successive timestamp but ordering is not deterministic or guaranteed within a single timestamp.
Deep discussions regarding diagram:
- no changes to X3D or HTML event-render loops are expected,
- keeping things as simple as possible in the specification is our preferred approach,
- If we add a diagram to specification, it should add value.
Even-simpler event diagram resulted, sketch attached (HtmlX3dEventExchangeSimple.jpg).
Existing X3D-only v3.3 specification:
4.4.8.3 Execution model, Figure 4.3 — Conceptual execution model
<a class="moz-txt-link-freetext" 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>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Past Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>