Fixed‑time‑step vs. variable‑time‑step: which better supports graceful cancellation in MonoGame?

Answer

When a CancellationToken is signaled, MonoGame will only stop the Update loop when it reaches a safe point inside Update or Draw. Neither time‑step mode automatically injects the token, so the developer must poll it. The choice of time‑step affects how quickly that polling can happen and how many Update calls may be queued.

Confirmed facts (MonoGame 4.8 and later)

• Fixed‑time‑step mode (IsFixedTimeStep = true) automatically calls Update multiple times per frame to catch up to TargetElapsedTime. Each call is bounded by the target time.
• Variable‑time‑step mode (IsFixedTimeStep = false) passes the actual elapsed time to Update. No additional Update calls are queued until the current call returns.
• Cancellation is cooperative; the token can only be acted upon inside Update or Draw or any blocking work called from them.
• In both modes, polling the token at the start of Update and returning immediately if cancelled prevents further heavy work for that frame.
• If Update performs blocking I/O or CPU‑bound work that cannot be interrupted, cancellation will not be detected until that work completes.

Likely explanation

Because each Update call in fixed‑time‑step mode is limited by TargetElapsedTime, a cancellation check at the beginning of Update is evaluated on a predictable cadence—roughly every 16 ms if the target is 60 Hz. This makes it easier to detect a cancellation before the next frame begins, and fewer frames are lost if the token is fired during a heavy frame.

In variable‑time‑step mode, the Update call receives the actual elapsed time. If that call takes longer than the frame budget, the next Update is delayed until the current one finishes, so the token check is only performed after the long work completes. The latency to react to cancellation is therefore bounded by the duration of the current Update.

In practice, the overhead of multiple Update calls per frame in fixed‑time‑step mode is usually negligible, but if you set an extremely small TargetElapsedTime (e.g., 1 ms) you may observe many rapid calls that could delay cancellation detection if a single call is blocked. Conversely, variable‑time‑step can be simpler to implement but gives no guarantee about how quickly cancellation will be noticed.

Implementation steps for graceful cancellation

1. Choose the time‑step mode that matches your determinism needs.
   • IsFixedTimeStep = true for deterministic physics or replay.
   • IsFixedTimeStep = false if you want a single Update per frame and can tolerate longer cancellation latency.
2. Poll the token early in Update.

   public override void Update(GameTime gameTime)
   {
       if (_cancellationToken.IsCancellationRequested)
       {
           // Skip heavy work and return immediately.
           return;
       }
       // Normal update logic here.
   }
   

3. Optionally inform Draw to skip rendering.

   private bool _cancelRequested;
   
   public override void Update(GameTime gameTime)
   {
       _cancelRequested = _cancellationToken.IsCancellationRequested;
       if (_cancelRequested) return;
       // ...heavy work
   }
   
   public override void Draw(GameTime gameTime)
   {
       if (_cancelRequested) return; // Skip drawing for this frame.
       // Normal draw logic
   }
   

4. Handle blocking work. If Update calls synchronous I/O or long CPU loops, wrap them in Task.Run or use CancellationToken-aware APIs so the operation can be cancelled before Update returns.
5. Test the cancellation path. Trigger the token after a short delay (e.g., 100 ms) while a 500 ms sleep simulates heavy work. Verify that no new Update calls occur and that Draw continues until the next frame boundary.

When to consider variable‑time‑step

If your game is heavily I/O‑bound and you want to avoid the overhead of multiple Update calls per frame, variable‑time‑step may be acceptable. Just remember that cancellation will only be detected after the current Update finishes.

Missing diagnostic detail

Does your Update method perform blocking I/O or CPU‑bound work that cannot be interrupted? If so, neither time‑step mode will interrupt that work; you must handle cancellation inside the blocking operation.