[x3d-public] event utility usage, and event tracing techniques

[Leonard Daly]

Andreas,

As Mike points out 20ms is significant. As 60fps, the system needs to 
generate a new frame every 16.6ms. Desired is > 90fps (or < 
11.1ms/frame). Could the DOM event be getting held up until after a 
frame is generated (20ms = 50fps)?


Leonard Daly



> 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.
>
>
> 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 
>> )
>>
>> 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
>
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org


-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161030/d9259981/attachment.html>