[x3d-public] event tracing

[Andreas Plesch]

On Mon, Oct 31, 2016 at 6:54 PM, Don Brutzman <brutzman at nps.edu> wrote:

> Tres cool, thank you for this information Andreas.
>
> 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).
>

Yes, I was surprised, too, that the console printing was so fast. Browsers
must have a smart way to do this.

I think that our key challenge with HTML5/DOM/X3D v4 remains pretty simple:
> getting event timing + synchronization well documented and confirmed
> consistent.  The hardest parts of that problem have each been sorted out
> wonderfully already, thanks to Moore's Law + ongoing browser/javascript
> optimizations + all our past work with SAI and X3D event models.
>

Agreed. Once there is a conforming x3d browser offering its services via
SAI on a web page, it is pretty simple to put together an integration layer.

When we say HTML5, I think we mean web page tags and their defined meaning,
but also the web page DOM API with lots of interfaces including for DOM
events. This is a change from HTML4 where the DOM was added on (AJAX) and
considered more separately.

A X3D XML document also has a XML DOM . But I think where the (SAI) spec.
mentions a DOM (eg., .importDocument (dom) ), it refers to a web page HTML
DOM.

Loosely coupled synchronization may be the main concept. I think this
mostly means that requested changes to the scenegraph via DOM methods
(.setAttribute, .appendNode) do not have a requirement to be considered by
the x3d browser in the current cascade but only as soon as possible
(normally the next cascade). The external SAI has somewhere a sentence on
how the x3d browser can collect external SAI requests into batches for
performance which may be a similar concept.

In terms of synchronization, there is also the consideration if there
should be a requirement that dynamic changes to the scene graph by x3d
internal scripts (which may create new nodes or change fields) should be
reflected to the parallel DOM tree. Currently, cobweb_dom does not do this,
mostly for performance but also for design reasons. I think x3dom actually
does this for (field) attribute changes via ROUTEs. The design reasons are
that internal changes to the scene graph are already communicated to the
DOM by events for output fields (ok, this brings up if input events should
also trigger DOM events), and that internal changes should be managed
internally. External changes to the scene graph are already represented in
the DOM tree (by necessity) and can be managed externally.

x3dom has a slightly different way to translate x3d output events to DOM
events. It has a single, all-purpose DOM event type for this purpose called
'outputchange':

http://doc.x3dom.org/tutorials/animationInteraction/onoutputchange/index.html

Listeners listening to this event then have to determine what kind of
output field was changed by checking the .fieldName event payload property.
I personally prefer to have DOM event types which exactly parallel the x3d
field names for ease of use but it would be straightforward to implement
the x3dom style in cobweb_dom. Thinking about it, it would also be possible
to dispatch both at the same time, for compatibility reasons.

Should web components and in particular HTML5 custom elements play a role ?
Perhaps only in terms of implementation  ? eg. X3D elements on a web page
can be considered HTMLUnknownElements (unregistered elements) but could
also be registered for implementation purposes ? Unknown elements are still
valid DOM nodes which have basic DOM methods.

-Andreas

-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161101/f0c317ff/attachment.html>