[x3d-public] HTML Events & Animation [was: X3D meeting minutes 1 MAR 2019: X3Dv4 architecture and event-exchange diagrams, progress review]

Fri Mar 1 20:14:33 PST 2019

Not sure how far down the thread to post a reply, so I'll do it from the 
top.

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.

*HTML Events*
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.

*Event Listeners*
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.

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).

*Event Processing*
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.

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.

*Event Practice*
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.

*Animation*
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.

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.

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.

*Document Comments*
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.

 1. 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
    https://developer.mozilla.org/en-US/docs/Web/Events
 2. A change to CSS that changes a node state (as opposed to directly
    changing a node's attribute value) is also an event (see
    https://developer.mozilla.org/en-US/docs/Web/Events#CSS_Animation_events).
 3. User interactions (key strokes, mouse state change (move, button,
    etc.) are also DOM events.
 4. Event listeners run as described above in the order described above.
 5. There is no cascade processing. Events generated by event listeners
    are handled on the next event cycle.
 6. Event listeners would be responsible for injecting relevant
    information/events into other (e.g., X3DOM) systems
 7. Browser window (or any block element) resize is an event

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).

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.

Leonard Daly

> ==================================
>
> 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
> 	http://www.web3d.org/x3d4
>
> 	X3D Futures: What is happening, how to get involved!
> 	Web3D 2018 Conference, Poznan Poland
> 	http://www.web3d.org/sites/default/files/page/X3D%20Version%204/X3dFuturesWeb3d2018PoznanPolandBrutzman.pdf
>
>            "Future of X3D" presentation and detailed notes from Web3D 2017 Conference, Brisbane Australia, 7 June 2017.
>            http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3D.pdf
>            http://www.web3d.org/sites/default/files/page/X3D%20Version%204/FutureOfX3dWeb3d2017June7.pdf
>            http://www.web3d.org/sites/default/files/image/wg/X3D%20Version%204/PresentationPanoramaFutureOfX3dPaulGrimm20170607_135611.1600x492.jpg
>
> 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
> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#ExecutionModel
>

-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Past Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190301/b44189e5/attachment-0001.html>