<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 31, 2016 at 6:54 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Tres cool, thank you for this information Andreas.<br>
<br>
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).<br></blockquote><div><br></div><div>Yes, I was surprised, too, that the console printing was so fast. Browsers must have a smart way to do this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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':</div><div><br></div><div><a href="http://doc.x3dom.org/tutorials/animationInteraction/onoutputchange/index.html">http://doc.x3dom.org/tutorials/animationInteraction/onoutputchange/index.html</a><br></div><div><br></div><div>Listeners listening to this event then have to determine what kind of output field was changed by checking the .fieldName event payload property.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Andreas</div><div><br></div></div>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>