[x3d-public] DOM integration with cobweb

[Andreas Plesch]

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.

Since there is enough functionality, I put the code in a release folder to
make it available from:

https://raw.githubusercontent.com/andreasplesch/cobweb_dom/master/release/cobweb_dom.0.1.js
or
https://rawgit.com/andreasplesch/cobweb_dom/master/release/cobweb_dom.0.1.js

Just load it after loading cobweb.[min].js.
There is a chance the code could work with D3 as a DOM manipulation library
but I did not test this.

Holger also implemented the .dispose() SAI function and other functionality
which should make the bridge code much cleaner.

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.

-Andreas


On Fri, Sep 16, 2016 at 12:15 AM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Thanks for looking at the example and code.
>
> I agree, it is cleanest just to get out of the way and let the sensor
> nodes do their work.
>
> 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.
>
> I will test on Chrome as well.
>
> On Sep 15, 2016 11:16 PM, "Joe D Williams" <joedwil at earthlink.net> wrote:
>
>> We need to look at issues between abstract SAI and ECMAscript SAI.
>>
>> //try out x3d events on touchsensor
>> ts = document.querySelector('TouchSensor');
>> coords = document.querySelector('#coords');
>> hitpt = document.querySelector('#hitpoint');
>> ts.addEventListener('isOver', function(evt) {
>> if (evt.value) {
>>  coords.textContent = " " + evt.fields.hitPoint_changed;
>>  //alert('isOver event:'+evt.value+'\nHitPoint:
>> '+evt.fields.hitPoint_changed)
>> }
>> });
>> ts.addEventListener('hitPoint_changed', function(evt) {
>> if (evt.value) {
>>  hitpt.textContent = " " + evt.value;
>>  //alert('isOver event:'+evt.value+'\nHitPoint:
>> '+evt.fields.hitPoint_changed)
>> }
>> });
>>
>> I think no way to do this without TouchSensor interfaces.
>> Seems more responsive than I expected. Modern browser scripting is much
>> improved.
>>
>> Fine example, Thanks
>>
>> All Best,,
>> JOe
>>
>> ----- Original Message ----- From: "Andreas Plesch" <
>> andreasplesch at gmail.com>
>> To: "Joe D Williams" <joedwil at earthlink.net>
>> Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org>; "John
>> Carlson" <yottzumm at gmail.com>
>> Sent: Thursday, September 15, 2016 7:16 AM
>> Subject: Re: [x3d-public] DOM integration with cobweb
>>
>>
>> Ok, I thought about relaying x3d sensor events to html DOM events a bit
>>> more and settled (for now) on requiring a x3d sensor (eg. TouchSensor).
>>>
>>> First, it turned out it was not necessary to modify cobweb in order to
>>> come
>>> up with a first demonstrator implementation of a x3d event to DOM event
>>> relay:
>>>
>>> https://andreasplesch.github.io/cobweb_dom/index.xhtml
>>>
>>> In the HTML each such sensor element would then be able to have listeners
>>> to DOM events with names corresponding the field names such as
>>> 'hitPoint_changed' or 'isOver'. So a web page programmer can then use
>>> sensorElement.addEventListener('hitPoint_changed',
>>> myhandlerfunction(event)) .The shortcut attributes onhitPoint_changed and
>>> such may be expected to be available as well but it would clutter the x3d
>>> xml and invalidate it. It is also not really necessary.
>>>
>>> In addition, it should be possible to also provide events with more
>>> familiar names such as 'click' as aliases for the field events.
>>>
>>> After carefully reading through the javascript SAI spec. I found the
>>> field.addFieldCallback() SAI function here:
>>>
>>> http://www.web3d.org/documents/specifications/19777-1/V3.3/P
>>> art1/functions.html#t-FieldFunctions
>>>
>>> It does not seem to have a corresponding service in the SAI spec.:
>>>
>>> http://www.web3d.org/documents/specifications/19775-2/V3.3/P
>>> art02/servRef.html#FieldServices
>>> ?
>>>
>>> But I was glad to see that the addFieldCallback() function is implemented
>>> in cobweb (although a little different from what the terse spec.
>>> suggests)
>>> and is a great way to hook into the field events. This is really what my
>>> relay is based on.
>>>
>>> The current implementation is restricted to TouchSensor but should cover
>>> all of its field events. For the event object which is passed to the DOM
>>> handler function, I added a .value property which has the value of the
>>> field, but also a .fields property which is an object containing all of
>>> the
>>> nodes fields for easy access. See example, and implementation in
>>> cobweb_dom.js
>>>
>>> It should be possible to generalize that to all sensor nodes, in fact the
>>> code is designed that way. Perhaps it makes sense to attach these field
>>> callbacks to all fields on all nodes, not just sensor nodes ?  To be able
>>> to pick up on interpolator events, for example ? It feels like this could
>>> affect performance since a lot of DOM events may be dispatched ? Well, it
>>> would come down to trying it.
>>>
>>> Any feedback or questions welcome,
>>>
>>> Andreas
>>>
>>>
>>> On Wed, Sep 14, 2016 at 6:34 PM, Joe D Williams <joedwil at earthlink.net>
>>> wrote:
>>>
>>> What I have in mind is to require x3d sensor nodes, unlike x3dom which
>>>>
>>>>>
>>>>> dispatches events on any shape.
>>>>
>>>> Fine, I would like to see that construction rather than the onclick and
>>>> html script.
>>>> All Best,
>>>> Joe
>>>>
>>>> ----- Original Message ----- From: "Andreas Plesch" <
>>>> andreasplesch at gmail.com>
>>>> To: "X3D Graphics public mailing list" <x3d-public at web3d.org>
>>>> Sent: Wednesday, September 14, 2016 12:58 PM
>>>> Subject: Re: [x3d-public] DOM integration with cobweb
>>>>
>>>>
>>>> Hello,
>>>>
>>>>>
>>>>> thanks to a transcontinental flight I made some progress on my bridge
>>>>> between the cobweb x3d scene graph and the DOM tree with x3d elements.
>>>>>
>>>>> Here are two simple examples:
>>>>>
>>>>> https://andreasplesch.github.io/cobweb_dom/addremoveNode.xhtml
>>>>>
>>>>> This is the x3dom add/remove nodes example (
>>>>> http://examples.x3dom.org/example/x3dom_addRemoveNode.html) with minor
>>>>> adjustments for xhtml but unchanged javascript control code.
>>>>>
>>>>> https://andreasplesch.github.io/cobweb_dom/index.xhtml
>>>>>
>>>>> This demonstrates both how html attribute changes are picked up by the
>>>>> x3d
>>>>> scene graph, and how adding and removing html elements also is
>>>>> reflected
>>>>> in
>>>>> the x3d scene graph. The box trafos are root nodes, and the removable
>>>>> Material node is a field of the Shape node.
>>>>>
>>>>> I put the bridge code in a separate file, so it can now be easily
>>>>> added to
>>>>> any page.
>>>>>
>>>>> The next step would be to translate x3d sensor events into appropriate
>>>>> DOM
>>>>> events. This will require probably more modification of the cobweb code
>>>>> itself and a clear strategy.
>>>>>
>>>>> What I have in mind is to require x3d sensor nodes, unlike x3dom which
>>>>> dispatches events on any shape.
>>>>>
>>>>> -Andreas
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 5, 2016 at 6:09 PM, Andreas Plesch <
>>>>> andreasplesch at gmail.com>
>>>>> wrote:
>>>>>
>>>>> I could generalize the handling of attribute changes by using the
>>>>> cobweb
>>>>>
>>>>>> parser, with only a few lines (but a lot of investigation). This means
>>>>>> that
>>>>>> most field types should be accessible from the DOM now. However, I
>>>>>> only
>>>>>> tested with diffuseColor. I also figured out how to immediately apply
>>>>>> the
>>>>>> changes by triggering a set event for the changed field.
>>>>>>
>>>>>> Adding and removing of nodes is next. I think statements also need
>>>>>> special
>>>>>> treatment. For external statement changes and prototype changes, it
>>>>>> may
>>>>>> be
>>>>>> best to reload the whole scene (?) .
>>>>>>
>>>>>> I adopted the x3dom basic attribute manipulation example:
>>>>>>
>>>>>> https://andreasplesch.github.io/cobweb_dom/jqueryui_cobweb.xhtml
>>>>>>
>>>>>> It worked without changes to the control code and demonstrates that
>>>>>> the
>>>>>> mutation observer is fast. This means it may be time to provide this
>>>>>> as a
>>>>>> simple js library to add on to cobweb pages since there is enough
>>>>>> functionality.
>>>>>>
>>>>>> -Andreas
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Sep 4, 2016 at 12:40 AM, Andreas Plesch <
>>>>>> andreasplesch at gmail.com
>>>>>> >
>>>>>> wrote:
>>>>>>
>>>>>> Here is a thought experiment which developed into a strawman
>>>>>>
>>>>>>> implementation.
>>>>>>>
>>>>>>> First the result:
>>>>>>>
>>>>>>> https://andreasplesch.github.io/cobweb_dom/index.xhtml
>>>>>>>
>>>>>>> After clicking the new color button, and moving the mouse, the color
>>>>>>> of
>>>>>>> the box should change.
>>>>>>>
>>>>>>> The interesting feature here is that the color change is triggered
>>>>>>> by a
>>>>>>> modification of the diffuseColor _attribute_ of the Material _html_
>>>>>>> element, in a way that should be possible to generalize to most (all)
>>>>>>> fields in x3d nodes.
>>>>>>>
>>>>>>> This is the x3dom pattern of controlling a x3d scene. But here I use
>>>>>>> cobweb as the x3d browser. Cobweb has very good coverage of the x3d
>>>>>>> standard including Prototypes, scripting and the SAI. Being able to
>>>>>>> use
>>>>>>> both, internal x3d scripting and external control using the DOM
>>>>>>> could be
>>>>>>> quite fruitful.
>>>>>>>
>>>>>>> I had to modify cobweb only slightly based on an idea developed
>>>>>>> during
>>>>>>> the discussion around the id attribute inspired by x3dom. The main
>>>>>>> change
>>>>>>> is to attach a reference to the generated x3d scene graph node from
>>>>>>> the
>>>>>>> DOM
>>>>>>> element during parsing. This then enables access from the DOM to the
>>>>>>> x3d
>>>>>>> node.
>>>>>>>
>>>>>>> The next step would be to expand to all field types, perhaps reusing
>>>>>>> the
>>>>>>> cobweb parser, or SAI functions. and to allow for removal and
>>>>>>> addition
>>>>>>> of
>>>>>>> nodes.
>>>>>>>
>>>>>>> [If all works, there is the issue of <script> being claimed by the
>>>>>>> web
>>>>>>> browser. I think the only solution may be to break backward
>>>>>>> compatibility
>>>>>>> and allow <x3dScript> as an alias to <script>]
>>>>>>>
>>>>>>> The examples also shows how to use inline x3d rather than an url with
>>>>>>> cobweb. Since cobweb is strict about XML, this is only possible if
>>>>>>> the
>>>>>>> html
>>>>>>> page has xhtml encoding. xhtml in turn triggered an issue with the
>>>>>>> fps
>>>>>>> counter display and the context menu, as a side note.
>>>>>>>
>>>>>>> The code is all on github: https://github.com/andreasples
>>>>>>> ch/cobweb_dom
>>>>>>>
>>>>>>> I had to learn a lot about cobweb (and jquery and AMD...) and look
>>>>>>> forward to any feedback or even hands-on contributions ? Perhaps the
>>>>>>> cobweb
>>>>>>> team is also interested ?
>>>>>>>
>>>>>>> -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/20160916/f04fc6b0/attachment-0001.html>