Update and Draw are called at different rates depending on whether IsFixedTimeStep is true or false. If IsFixedTimeStep is false, Update and Draw will be called sequentially as often as possible. If IsFixedTimeStep is true, Update will be called at the interval specified in TargetElapsedTime, while Draw will continue to be called as often as possible.

What is the point of calling Draw potentially more often than Update? Why is Draw not upper-limited to the number of Update calls?

It is very interesting that Shawn essentially contradicts the text quoted from MSDN when he says, "we call Update, then call Draw, then look at the clock, notice we have some time left over, so wait around twiddling our thumbs until it is time to call Update again". His explanation makes more sense to me, unless XNA can perform interpolation between states, in which case more Draws than Updates might work.
–
KylotanFeb 21 '13 at 12:25

1

You can write your own interpolation in the draw method. Also Shawn does not contradict MSDN, as the default option for XNA is to have IsFixedTimeStep=true :)
–
Roy T.Feb 21 '13 at 13:53

@RoyT., I'm talking about what Shawn is saying for the IsFixedTimeStep=true case. It's the 3rd or 4th paragraph down in that section.
–
KylotanFeb 21 '13 at 16:24

@Kylotan, you're right. I must've misread that. The behavior described on MSDN is true for XNA1,2 and maybe even 3, but in 4 they fixed it as Shawn says on his blog. Maybe they forgot to update MSDN?
–
Roy T.Feb 21 '13 at 21:00

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.

You also need to disable SynchronizeWithVerticalRetrace on the graphics device manager or you will still be capped at the monitor refresh rate.
–
dadoo GamesFeb 21 '13 at 14:28

1

The behaviour you describe is set up to work against lagging gameplay. Because Update still triggers with 60 fps your game logic will be stable. As well as draw not beeing called so often your game will get the 'is running slow' flag set. So you can tune down your effects or graphic stuff so your Draw calls can catch up
–
floArFeb 21 '13 at 14:42

However, even with fixed time stamp and update less than 60 FPS, Draw is still not called more often than Update, contrary to the MSDN statement. Also, why does the monitor refresh rate affect the Update FPS? With synched graphics and no fixed time stamp, update gets called at only 60 FPS.
–
HackworthFeb 21 '13 at 14:58

I updated my answer, but most of my findings still stand.
–
HackworthFeb 21 '13 at 15:10