After reading the article floAr linked, I also wondered why the author of that article seemed to contradict the MSDN page in places, and I started experimenting on the XNA shooter tutorial a little with the following findings:
Draw is called as often as Update if possible, but not more often, contrary to the MSDN statement about fixed time stamp
If IsFixedTimeStep == false, then TargetElapsedTime gets ignored as expected, but Update, and therefore Draw, are still capped at the monitor refresh rate and not unlimited as the MSDN page suggests. To get more Update FPS than the monitor refresh rate, you have to disable monitor refresh rate synching or use a fixed time stamp and set the value lower than the default 16.6 milliseconds.
By using a StopWatch-controlled empty while-loop, I simulated a very expensive Update method.
- When IsFixedTimeStep == true and the delay would approach but not surpass TargetElapsedTime (for example delay = 16.1, target = 16.6), the Drawing FPS would rapidly fall behind Update FPS. If the delay was even slightly above the target (e.g. 17.0 and 16.6), the update FPS were as expected by the set delay, but the drawing FPS would go way below that. So not only drawing was slow, there was a disconnect between updating and drawing, which makes for severely lagging gameplay.
- When IsFixedTimeStep == false, there is no disconnect, because even for large values of delay, the drawing FPS was the same as the update FPS. Both are slow, but they are equally slow.
So in essence, without completely breaking the XNA game loop by calling Draw whenever you feel like it, you can only influence the number of calls per second to Update, and Draw will be called at most once per Update under any circumstances.