get first frame during initialize and start paused #457
Conversation
…rium/simularium-viewer into feature/prefetching-fixes
… run is open ended
| @@ -247,6 +247,9 @@ export class RemoteSimulator implements ISimulator { | |||
| "Start Trajectory File Playback" | |||
| ); | |||
| }) | |||
| .then(() => { | |||
| this.requestFrame(0); | |||
| }) | |||
There was a problem hiding this comment.
Since the websocket request is not a promise my understanding is there is no guarantee that the request has completed before this next block is executed. Could that cause any problems?
There was a problem hiding this comment.
In practice, they seem to be landing in the proper order without issue, but you're right that there is no guarantee without a promise, which theoretically makes a race condition here.
The most precise fix here would be to change sendWebSocketRequest to return a promise. Hackier fix would be to resolve a Promise here with a tiny arbitrary delay, or just leave as is for the moment because things seem to be landing in the correct order.
There was a problem hiding this comment.
could you move the this.requestFrame within the webSocketRequest switch bracket?
src/test/DummyRemoteSimulator.ts
Outdated
| }) | ||
| .then(() => { | ||
| this.requestFrame(0); | ||
| }); |
There was a problem hiding this comment.
I feel like I asked about this before, but can’t this.requestFrame(0) just be in the previous block?
| @@ -433,7 +412,7 @@ export default class SimulariumController { | |||
| // calls simulator.abort() | |||
| this.stop(); | |||
|
|
|||
| this.visData.WaitForFrame(0); | |||
| this.visData.waitForFrame(0); | |||
There was a problem hiding this comment.
What’s the difference between waitForFrame and requestFrame?
There was a problem hiding this comment.
requestFrame is a core method on ISimulator intended to be the way that the front end requests a single frame of data from a simulator by passing in a frame number.
waitForFrame is something internal to visData that basically sets an internal flags lockedForFrame and frameToWaitFor in order to reject incoming frames that are not the one we most recently requested. I haven't really put a lot of thought into this set up as it predates me and I haven't had much need to change/use it, but that's my understanding.
interim17
requested review from
meganrm,
ShrimpCryptid and
toloudis
and removed request for
a team
Time Estimate or Size
medium
Problem
@meganrm found some bugs resulting from recent prefetching branch merge
Solution
These changes:
isPreFetching(along withisPlaying) as state variable to control prefetching behavior (previously:streaming)totalStepsin client simulators to beInfinitybecause frame clamping ingoToFramewas conflicting withtotalStepsthat were lower than the number of frames actually emitted by the binding siminitializemethods to always request frame 0 during initializationThis is intended as a prompt fix for bugs, and implies a few ongoing pieces of work: