<div dir="ltr"><div>Here is what I found:</div><div><br></div>The function name is is actually field.addFieldCallback() .<div><br></div><div>1) added field callbacks are called in processEvent() in cobweb:</div><div><br></div><div><a href="https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Basic/X3DField.js#L281">https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Basic/X3DField.js#L281</a><br></div><div><br></div><div>2) processEvent() is called from processEvents() in cobweb here:</div><div><br></div><div><a href="https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Routing/X3DRoutingContext.js#L90">https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Routing/X3DRoutingContext.js#L90</a><br></div><div><br></div><div>3) processEvents() is called twice from traverse() here:</div><div><br></div><div><a href="https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Browser/X3DBrowserContext.js#L257">https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Browser/X3DBrowserContext.js#L257</a><br></div><div><br></div><div>before a DISPLAY traverse. This looks like the main per-frame work function.</div><div><br></div><div>So it looks like the DOM events would be dispatched just before things are drawn via webgl. To me, this means that any changes to fields via dom event handlers (via cobweb_dom) will be picked up only in the next frame (at the earliest). It might be better to create and dispatch the DOM events just after drawing the frame, so there is a chance that resulting updates make it into the next frame (?). Unfortunately, I do not know how to do that. [ There is a .finished_.processInterests() which means it may be possible to add a callback as an interest to the 'finished' field (of the browser) (but x3d events are processed by then so I am not sure how to know which events had happened). I seem to recall a addInterest() SAI function. ]</div><div><br></div><div>4) traverse() is copied to .renderCallback for each browser context and called from addBrowserEvent():</div><div><br></div><div><a href="https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Browser/X3DBrowserContext.js#L139">https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Browser/X3DBrowserContext.js#L139</a><br></div><div><br></div><div><a href="https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Browser/X3DBrowserContext.js#L246">https://github.com/create3000/cobweb/blob/master/cobweb.js/cobweb/Browser/X3DBrowserContext.js#L246</a></div><div><br></div><div>as the callback for requestAnimationFrame() . The web browser invokes these callbacks whenever it is ready to draw the next frame but at 60 fps at the most. This would be place to use the webvr RAF which allows higher frame rates. ( The cobweb reported fps for me is always below 30. ) .</div><div><br></div><div>It looks like there is only rendering when addBrowserEvent() is called, for example during navigation.</div><div><br></div><div>5) addBrowserEvent() is called from various places:</div><div><br></div><div><a href="https://github.com/create3000/cobweb/search?q=addBrowserEvent">https://github.com/create3000/cobweb/search?q=addBrowserEvent</a><br></div><div><br></div><div>seemingly to ensure render updates.</div><div><br></div><div>It was good for me to get a sense of how cobweb works anyways. Perhaps it is helpful in general,</div><div><br></div><div>-Andreas</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 31, 2016 at 10:26 AM, Andreas Plesch <span dir="ltr"><<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 31, 2016 at 9:48 AM, <span dir="ltr"><<a href="mailto:x3d-public-request@web3d.org" target="_blank">x3d-public-request@web3d.org</a>></span> wrote:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Date: Sun, 30 Oct 2016 16:08:18 -0700<br>
From: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.com</a>><br>
To: <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
Subject: Re: [x3d-public] event utility usage, and event tracing<br>
techniques<br><br>
Andreas,<br>
<br>
As Mike points out 20ms is significant. As 60fps, the system needs to<br>
generate a new frame every 16.6ms. Desired is > 90fps (or <<br>
11.1ms/frame). Could the DOM event be getting held up until after a<br>
frame is generated (20ms = 50fps)?<br>
<br></blockquote><div><br></div><div>The DOM event is created by the SAI field.addEventCallback() method .</div><div><br></div><div>What does the SAI standard say about when an added event callback should be invoked ?</div><div>Presumably as part of the same event cascade when the x3d event is created but is there guidance ? </div><div><br></div><div>I see if I can figure out from looking at the cobweb source when exactly the callback is called but perhaps Holger can chime in ?</div><div><br></div><div>My working hypothesis to test would be at the end of the event processing but before the draw traversal, at a given time stamp.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Andreas</div></font></span></div>
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div>