<div dir="ltr"><div><div><div>Holger was kind enough to amend cobweb in its latest release to allow convenient access to its x3d nodes from a custom property added to DOM nodes within the x3d scene. This means that the (experimental) dom bridge code now works with the regular cobweb release.<br><br></div>Since there is enough functionality, I put the code in a release folder to make it available from:<br><br><a href="https://raw.githubusercontent.com/andreasplesch/cobweb_dom/master/release/cobweb_dom.0.1.js">https://raw.githubusercontent.com/andreasplesch/cobweb_dom/master/release/cobweb_dom.0.1.js</a><br></div>or<br><a href="https://rawgit.com/andreasplesch/cobweb_dom/master/release/cobweb_dom.0.1.js">https://rawgit.com/andreasplesch/cobweb_dom/master/release/cobweb_dom.0.1.js</a><br></div><div><br>Just load it after loading cobweb.[min].js.<br></div>There is a chance the code could work with D3 as a DOM manipulation library but I did not test this.<br><div><div><div><div><br><div class="gmail_extra">Holger also implemented the .dispose() SAI function and other functionality which should make the bridge code much cleaner.<br><br></div><div class="gmail_extra">Also, it turns out that my performance issues were not due to the event handling but just a very busy PC with its 32GB memory completely filled up. But I do suspect that cobweb is more memory demanding and prone to more frequent GC stuttering than x3dom is.<br><br></div><div class="gmail_extra">-Andreas<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 16, 2016 at 12:15 AM, Andreas Plesch <span dir="ltr"><<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</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"><p dir="ltr">Thanks for looking at the example and code.</p>
<p dir="ltr">I agree, it is cleanest just to get out of the way and let the sensor nodes do their work.</p>
<p dir="ltr">I noticed that after adding the event listeners to my example, spinning the view now is not continues, in FF. Using the performance developer tools, it turns out that the short breaks in spinning are caused by garbage collection of the js engine. Apparently, much more garbage generated now, perhaps by the field callbacks. They may be processed on every frame (?). Will do some tests.</p>
<p dir="ltr">I will test on Chrome as well. </p>
<div class="gmail_extra"><br><div class="gmail_quote">On Sep 15, 2016 11:16 PM, "Joe D Williams" <<a href="mailto:joedwil@earthlink.net" target="_blank">joedwil@earthlink.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We need to look at issues between abstract SAI and ECMAscript SAI.<br>
<br>
//try out x3d events on touchsensor<br>
ts = document.querySelector('TouchS<wbr>ensor');<br>
coords = document.querySelector('#coord<wbr>s');<br>
hitpt = document.querySelector('#hitpo<wbr>int');<br>
ts.addEventListener('isOver', function(evt) {<br>
if (evt.value) {<br>
 coords.textContent = " " + evt.fields.hitPoint_changed;<br>
 //alert('isOver event:'+evt.value+'\nHitPoint: '+evt.fields.hitPoint_changed)<br>
}<br>
});<br>
ts.addEventListener('hitPoint_<wbr>changed', function(evt) {<br>
if (evt.value) {<br>
 hitpt.textContent = " " + evt.value;<br>
 //alert('isOver event:'+evt.value+'\nHitPoint: '+evt.fields.hitPoint_changed)<br>
}<br>
});<br>
<br>
I think no way to do this without TouchSensor interfaces.<br>
Seems more responsive than I expected. Modern browser scripting is much improved.<br>
<br>
Fine example, Thanks<br>
<br>
All Best,,<br>
JOe<br>
<br>
----- Original Message ----- From: "Andreas Plesch" <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
To: "Joe D Williams" <<a href="mailto:joedwil@earthlink.net" target="_blank">joedwil@earthlink.net</a>><br>
Cc: "X3D Graphics public mailing list" <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>; "John Carlson" <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>><br>
Sent: Thursday, September 15, 2016 7:16 AM<br>
Subject: Re: [x3d-public] DOM integration with cobweb<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Ok, I thought about relaying x3d sensor events to html DOM events a bit<br>
more and settled (for now) on requiring a x3d sensor (eg. TouchSensor).<br>
<br>
First, it turned out it was not necessary to modify cobweb in order to come<br>
up with a first demonstrator implementation of a x3d event to DOM event<br>
relay:<br>
<br>
<a href="https://andreasplesch.github.io/cobweb_dom/index.xhtml" rel="noreferrer" target="_blank">https://andreasplesch.github.i<wbr>o/cobweb_dom/index.xhtml</a><br>
<br>
In the HTML each such sensor element would then be able to have listeners<br>
to DOM events with names corresponding the field names such as<br>
'hitPoint_changed' or 'isOver'. So a web page programmer can then use<br>
sensorElement.addEventListener<wbr>('hitPoint_changed',<br>
myhandlerfunction(event)) .The shortcut attributes onhitPoint_changed and<br>
such may be expected to be available as well but it would clutter the x3d<br>
xml and invalidate it. It is also not really necessary.<br>
<br>
In addition, it should be possible to also provide events with more<br>
familiar names such as 'click' as aliases for the field events.<br>
<br>
After carefully reading through the javascript SAI spec. I found the<br>
field.addFieldCallback() SAI function here:<br>
<br>
<a href="http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/functions.html#t-FieldFunctions" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19777-1/V3.3/P<wbr>art1/functions.html#t-FieldFun<wbr>ctions</a><br>
<br>
It does not seem to have a corresponding service in the SAI spec.:<br>
<br>
<a href="http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#FieldServices" rel="noreferrer" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-2/V3.3/P<wbr>art02/servRef.html#FieldServic<wbr>es</a><br>
?<br>
<br>
But I was glad to see that the addFieldCallback() function is implemented<br>
in cobweb (although a little different from what the terse spec. suggests)<br>
and is a great way to hook into the field events. This is really what my<br>
relay is based on.<br>
<br>
The current implementation is restricted to TouchSensor but should cover<br>
all of its field events. For the event object which is passed to the DOM<br>
handler function, I added a .value property which has the value of the<br>
field, but also a .fields property which is an object containing all of the<br>
nodes fields for easy access. See example, and implementation in<br>
cobweb_dom.js<br>
<br>
It should be possible to generalize that to all sensor nodes, in fact the<br>
code is designed that way. Perhaps it makes sense to attach these field<br>
callbacks to all fields on all nodes, not just sensor nodes ?  To be able<br>
to pick up on interpolator events, for example ? It feels like this could<br>
affect performance since a lot of DOM events may be dispatched ? Well, it<br>
would come down to trying it.<br>
<br>
Any feedback or questions welcome,<br>
<br>
Andreas<br>
<br>
<br>
On Wed, Sep 14, 2016 at 6:34 PM, Joe D Williams <<a href="mailto:joedwil@earthlink.net" target="_blank">joedwil@earthlink.net</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
What I have in mind is to require x3d sensor nodes, unlike x3dom which<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
</blockquote>
dispatches events on any shape.<br>
<br>
Fine, I would like to see that construction rather than the onclick and<br>
html script.<br>
All Best,<br>
Joe<br>
<br>
----- Original Message ----- From: "Andreas Plesch" <<br>
<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
To: "X3D Graphics public mailing list" <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
Sent: Wednesday, September 14, 2016 12:58 PM<br>
Subject: Re: [x3d-public] DOM integration with cobweb<br>
<br>
<br>
Hello,<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
thanks to a transcontinental flight I made some progress on my bridge<br>
between the cobweb x3d scene graph and the DOM tree with x3d elements.<br>
<br>
Here are two simple examples:<br>
<br>
<a href="https://andreasplesch.github.io/cobweb_dom/addremoveNode.xhtml" rel="noreferrer" target="_blank">https://andreasplesch.github.i<wbr>o/cobweb_dom/addremoveNode.xht<wbr>ml</a><br>
<br>
This is the x3dom add/remove nodes example (<br>
<a href="http://examples.x3dom.org/example/x3dom_addRemoveNode.html" rel="noreferrer" target="_blank">http://examples.x3dom.org/exam<wbr>ple/x3dom_addRemoveNode.html</a>) with minor<br>
adjustments for xhtml but unchanged javascript control code.<br>
<br>
<a href="https://andreasplesch.github.io/cobweb_dom/index.xhtml" rel="noreferrer" target="_blank">https://andreasplesch.github.i<wbr>o/cobweb_dom/index.xhtml</a><br>
<br>
This demonstrates both how html attribute changes are picked up by the x3d<br>
scene graph, and how adding and removing html elements also is reflected<br>
in<br>
the x3d scene graph. The box trafos are root nodes, and the removable<br>
Material node is a field of the Shape node.<br>
<br>
I put the bridge code in a separate file, so it can now be easily added to<br>
any page.<br>
<br>
The next step would be to translate x3d sensor events into appropriate DOM<br>
events. This will require probably more modification of the cobweb code<br>
itself and a clear strategy.<br>
<br>
What I have in mind is to require x3d sensor nodes, unlike x3dom which<br>
dispatches events on any shape.<br>
<br>
-Andreas<br>
<br>
<br>
<br>
<br>
On Mon, Sep 5, 2016 at 6:09 PM, Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>><br>
wrote:<br>
<br>
I could generalize the handling of attribute changes by using the cobweb<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
parser, with only a few lines (but a lot of investigation). This means<br>
that<br>
most field types should be accessible from the DOM now. However, I only<br>
tested with diffuseColor. I also figured out how to immediately apply the<br>
changes by triggering a set event for the changed field.<br>
<br>
Adding and removing of nodes is next. I think statements also need<br>
special<br>
treatment. For external statement changes and prototype changes, it may<br>
be<br>
best to reload the whole scene (?) .<br>
<br>
I adopted the x3dom basic attribute manipulation example:<br>
<br>
<a href="https://andreasplesch.github.io/cobweb_dom/jqueryui_cobweb.xhtml" rel="noreferrer" target="_blank">https://andreasplesch.github.i<wbr>o/cobweb_dom/jqueryui_cobweb.x<wbr>html</a><br>
<br>
It worked without changes to the control code and demonstrates that the<br>
mutation observer is fast. This means it may be time to provide this as a<br>
simple js library to add on to cobweb pages since there is enough<br>
functionality.<br>
<br>
-Andreas<br>
<br>
<br>
<br>
On Sun, Sep 4, 2016 at 12:40 AM, Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a><br>
><br>
wrote:<br>
<br>
Here is a thought experiment which developed into a strawman<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
implementation.<br>
<br>
First the result:<br>
<br>
<a href="https://andreasplesch.github.io/cobweb_dom/index.xhtml" rel="noreferrer" target="_blank">https://andreasplesch.github.i<wbr>o/cobweb_dom/index.xhtml</a><br>
<br>
After clicking the new color button, and moving the mouse, the color of<br>
the box should change.<br>
<br>
The interesting feature here is that the color change is triggered by a<br>
modification of the diffuseColor _attribute_ of the Material _html_<br>
element, in a way that should be possible to generalize to most (all)<br>
fields in x3d nodes.<br>
<br>
This is the x3dom pattern of controlling a x3d scene. But here I use<br>
cobweb as the x3d browser. Cobweb has very good coverage of the x3d<br>
standard including Prototypes, scripting and the SAI. Being able to use<br>
both, internal x3d scripting and external control using the DOM could be<br>
quite fruitful.<br>
<br>
I had to modify cobweb only slightly based on an idea developed during<br>
the discussion around the id attribute inspired by x3dom. The main<br>
change<br>
is to attach a reference to the generated x3d scene graph node from the<br>
DOM<br>
element during parsing. This then enables access from the DOM to the x3d<br>
node.<br>
<br>
The next step would be to expand to all field types, perhaps reusing the<br>
cobweb parser, or SAI functions. and to allow for removal and addition<br>
of<br>
nodes.<br>
<br>
[If all works, there is the issue of <script> being claimed by the web<br>
browser. I think the only solution may be to break backward<br>
compatibility<br>
and allow <x3dScript> as an alias to <script>]<br>
<br>
The examples also shows how to use inline x3d rather than an url with<br>
cobweb. Since cobweb is strict about XML, this is only possible if the<br>
html<br>
page has xhtml encoding. xhtml in turn triggered an issue with the fps<br>
counter display and the context menu, as a side note.<br>
<br>
The code is all on github: <a href="https://github.com/andreasplesch/cobweb_dom" rel="noreferrer" target="_blank">https://github.com/andreasples<wbr>ch/cobweb_dom</a><br>
<br>
I had to learn a lot about cobweb (and jquery and AMD...) and look<br>
forward to any feedback or even hands-on contributions ? Perhaps the<br>
cobweb<br>
team is also interested ?<br>
<br>
-Andreas<br>
<br></blockquote><br></blockquote></blockquote></blockquote></blockquote></blockquote></div></div></blockquote></div>-- <br><div class="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div></div></div></div></div>