[x3d-public] event tracing
Don Brutzman
brutzman at nps.edu
Mon Oct 31 15:54:32 PDT 2016
Tres cool, thank you for this information Andreas.
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).
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.
This might seem surprising until you think of Web browser as "universal OS" or part of Open Web Platform (OWP). Then the optimization imperatives become obvious.
http://www.infoworld.com/article/2609165/web-browsers/10-reasons-the-browser-is-becoming-the-universal-os.html
https://www.w3.org/wiki/Open_Web_Platform
Onward we go, at fully interactive frame rates! 8)
On 10/31/2016 6:46 AM, Andreas Plesch wrote:
> 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 <mailto:andreasplesch at gmail.com>> wrote:
>
> Date: Sun, 30 Oct 2016 09:34:38 -0700
>
> From: Michael Aratow <maratow at noegenesis.com <mailto:maratow at noegenesis.com>>
> To: x3d-public at web3d.org <mailto: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 <mailto: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/interactiveTransformations.xhtml <https://andreasplesch.github.io/cobweb_dom//tests/interactiveTransformations.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> <mailto: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>
> > <mailto: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 <mailto:x3d-public at web3d.org>
> > http://web3d.org/mailman/listinfo/x3d-public_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 <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 <mailto:x3d-public at web3d.org>
> http://web3d.org/mailman/listinfo/x3d-public_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
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
More information about the x3d-public
mailing list