Snapshot Movie throughput test

At the END of OnDraw:

if (m_hMovieFile != INVALID_HANDLE_VALUE) { // if we're recording a snapshot movie
  CBenchmark b;
  CSnapshot* pSnapshot = GetSnapshot(); // get the snapshot (allocates on heap)
  DWORD	bWritten;
  WriteFile(m_hMovieFile, pSnapshot, pSnapshot->GetSize(), &bWritten, NULL); // write the snapshot
  delete pSnapshot; // delete the snapshot
  stats.Print(b.Elapsed());
}

And open the file somewhere:

m_hMovieFile = CreateFile(_T("test.whm"),
  GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);

Don't forget to also CLOSE the file via CloseHandle.

The statistics:

minimum: 13 µs
maximum: 175 µs
average: 45 µs
standard deviation: 35 µs

Sample size: 60 (one second at 60 Hz)

Every now and then I see a maximum two orders of magnitude larger, in the range of 3 ms to 6 ms. This is long enough to worry about, and possibly sufficient justification for asynchronous writes, using either a single buffer, or a fancy ring of buffers as GPT suggests.

Asynchronous I/O is ideal when the application can do other work while the I/O is completing, and that's certainly the case here. Whorld can block in Present, and then completely draw the next frame before it needs the result of the previous write. Using a multi-buffer model, it could go even longer without waiting.

This same justification could apply when playing back the movie! By using asynchronous reads and a ring of buffers, it would be possible to stay several frames ahead, so that while the render thread is drawing or presenting the current frame, the OS is busy reading the next frame(s).

Given how complex all that is, it should definitely be wrapped in an object.