[x3d-public] DOM integration with cobweb
Holger Seelig
holger.seelig at yahoo.de
Fri Sep 16 13:41:24 PDT 2016
Would like to include your fantastic work in the next official release,
with some documentation added.
Cheers,
Holger
Am 16.09.2016 um 21:54 schrieb 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 <mailto: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
> <mailto: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 <mailto:andreasplesch at gmail.com>>
> To: "Joe D Williams" <joedwil at earthlink.net
> <mailto:joedwil at earthlink.net>>
> Cc: "X3D Graphics public mailing list" <x3d-public at web3d.org
> <mailto:x3d-public at web3d.org>>; "John Carlson"
> <yottzumm at gmail.com <mailto: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
> <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/Part1/functions.html#t-FieldFunctions
> <http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/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/Part02/servRef.html#FieldServices
> <http://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/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 <mailto: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 <mailto:andreasplesch at gmail.com>>
> To: "X3D Graphics public mailing list"
> <x3d-public at web3d.org <mailto: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
> <https://andreasplesch.github.io/cobweb_dom/addremoveNode.xhtml>
>
> This is the x3dom add/remove nodes example (
> http://examples.x3dom.org/example/x3dom_addRemoveNode.html
> <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
> <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
> <mailto: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
> <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
> <mailto: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
> <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/andreasplesch/cobweb_dom
> <https://github.com/andreasplesch/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
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
--
Holger Seelig
Mediengestalter Digital – Digital Media Designer
Scheffelstraße 31a
04277 Leipzig
Germany
Cellular: +49 1577 147 26 11
E-Mail: holger.seelig at create3000.de
Web: http://titania.create3000.de
Future to the fantasy ★ ★
More information about the x3d-public
mailing list