<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 31, 2016 at 6:54 PM, Don Brutzman <span dir="ltr"><<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Tres cool, thank you for this information Andreas.<br>
<br>
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).<br></blockquote><div><br></div><div>I slightly updated the event logging to use performance.now rather than event.timeStamp which is consistent across browsers and to also report the difference between the x3d timestamp and the time of logging which should happen just after dispatching of the DOM event and before drawing to the webgl canvas. The x3d timestamp is created at the beginning of processing of x3d events for each cascade, I believe. This difference varies considerably, about between 2 ms and 20 ms, even for repeats of the same events. Chrome shows a little less difference on average. So I am not sure how accurate these timings are in relation to when things really happen and what external factors influence these.</div><div><br></div><div><a href="https://andreasplesch.github.io/cobweb_dom/tests/interactiveTransformations.xhtml">https://andreasplesch.github.io/cobweb_dom/tests/interactiveTransformations.xhtml</a><br></div><div><br></div><div>-Andreas</div></div>
</div></div>