[x3d-public] event tracing
Andreas Plesch
andreasplesch at gmail.com
Mon Oct 31 06:46:52 PDT 2016
The cobweb_dom event logger now includes the x3d time stamp for each event:
https://andreasplesch.github.io/cobweb_dom/tests/interactiveTransformations.xhtml
For documentation purposes some related findings:
Looking at Chrome, it turns out that Chrome reports dom event creation time
stamps in (hi-res) milliseconds after initial page loading:
https://developers.google.com/web/updates/2016/01/high-res-timestamps
Firefox, on the other hand, reports in integer microseconds after 1970.
Both, therefore, do not follow the DOM spec. which says time stamps should
be in milliseconds after 1970:
http://www.w3.org/TR/dom/#dom-event-timestamp
Firefox documentation apparently needs to be updated:
https://developer.mozilla.org/en-US/docs/Web/API/Event/timeStamp
(Perhaps event.timeStamp was not available until recently?)
-Andreas
On Sun, Oct 30, 2016 at 2:06 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:
> Date: Sun, 30 Oct 2016 09:34:38 -0700
>
>> From: Michael Aratow <maratow at noegenesis.com>
>> To: x3d-public at web3d.org
>> Subject: Re: [x3d-public] event utility usage, and event tracing
>> techniques
>> Message-ID: <2037c542-880d-58ea-01b4-b03cf24f80c4 at noegenesis.com>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> If we take WebVR into consideration, these types of delays are
>> significant.
>>
>> Do you anticipate problems? End to end system delay in VR systems must
>> be 20 milliseconds or less to avoid simulator sickness.
>>
>
> I am not sure these can be called delays. The actual rendering time of the
> frame is not the bind time (of a viewpoint) but occurs afterwards.
>
> Latency would be the time from some input via a controller to the time the
> input has an effect on the rendering.
>
> Not sure how to measure this. cobweb has timing measurements to show how
> much time is spent for various processing steps.
>
> Overall, I would expect that there will be a penalty for using the DOM to
> control a scene, and that there is room for using a predictive capability
> to reduce perceived latency.
>
> A-Frame and three.js are trying hard to reduce latency. It will be
> difficult to improve on or match their efforts.
>
> -Andreas
>
> On 10/30/16 7:59 AM, Andreas Plesch wrote:> Hello,>
>
>> > cobweb_dom v0.7 is now available. It has full support for
>> > ProtoInstance nodes and basic event tracing capability.
>> >
>> > v0.7 requires the latest development cobweb.js, eg cobweb > 2.3 .
>> >
>> > Event tracing to the console can be enabled by providing a 'trace'
>> > attribute to the X3DCanvas element (with any value).
>> >
>> > All output x3d events are logged. Here is an example:
>> >
>> > 1477837418917000: Background x3d_isBound: true
>> > 1477837418918000: Background x3d_bindTime: 1477837418.9007943
>> > 1477837418919000: Viewpoint x3d_isBound: true
>> > 1477837418920000: Viewpoint x3d_bindTime: 1477837418.9007943
>> > 1477837421509000: CylinderSensor aroundX x3d_isOver: true
>> > ...
>> >
>> > (using
>> > https://andreasplesch.github.io/cobweb_dom//tests/interactiv
>> eTransformations.xhtml
>> > )
>> >
>> > The frontal time stamp is the DOM event creation time stamp in
>> > microseconds produced by the web browser and available to DOM event
>> > listeners.
>> > It is interesting to see the difference between the time stamp and say
>> > the bindTime of the Background node, 18.918s - 18.901s = 17 ms
>> > or for Viewpoint: 18.920 - 18.901 = 19 ms.
>> > So it takes a bit for cobweb to call the event callback which creates
>> > the DOM event.
>> > When a DOM event listener captures the event, it may be a little later
>> > again.
>> > With a fps of 30, a frame lasts 33ms.
>> > It will be interesting to compare what time stamps and values are
>> > reported with the x3d-edit trace scripts.
>> >
>> > -Andreas
>> >
>> >
>> >
>> > On Sat, Oct 29, 2016 at 8:00 PM, Andreas Plesch
>> > <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>> wrote:
>> >
>> > On Oct 29, 2016 6:20 PM, "Don Brutzman" <brutzman at nps.edu
>> > <mailto:brutzman at nps.edu>> wrote:
>> > >
>> > > On 10/29/2016 2:21 PM, Andreas Plesch wrote:
>> > >>
>> > >> [...]
>> > >>
>> > >> Since logging all fields for all nodes becomes quickly a bit
>> > overwhelming, it would be a nice touch to be able select in the
>> > GUI which fields are traced (by default all).
>> > >
>> > >
>> > > excellent idea. not easily accomplished with current setup, but
>> > will keep it in mind as a future feature in X3D-Edit.
>> > >
>> > > for that matter, couldn't someone someday somewhere create such
>> > a widget in HTML that listened to all ROUTEs, as selected? 8)
>> >
>> > It should be possible find all elements referenced by fromNode
>> > attributes in ROUTE elements and attach event listeners with
>> > handlers which just log to the console. Let me give it a try.
>> >
>> > 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
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments
>> /20161030/b0184271/attachment.html>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>> ------------------------------
>>
>> End of x3d-public Digest, Vol 91, Issue 81
>> ******************************************
>>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>
--
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/20161031/ff7c2add/attachment-0001.html>
More information about the x3d-public
mailing list