Why is Frame Rate in WPF Irregular and Not Limited To Monitor Refresh?

I raised this question with the WPF team and here is a summary of the response I was given:

Calculating the framerate from the UI
thread is difficult. WPF decouples
the UI thread from the render thread.
The UI thread will render:

  • Whenever something is marked as dirty and we drain down to Render
    priority. This can happen more often
    than the refresh rate.

  • If an animation is pending (or if someone hooked the
    CompositionTarget.Rendering event) we
    will render on the UI thread after
    every present from the render thread.
    This involves advancing the timing
    tree so animations calculate their new
    values.

Because of this, the
CompositionTarget.Rendering event can
be raised multiple times per “frame”.
We report the intended “frame time” in
the RenderingEventArgs, and
applications should only do
“per-frame” work when the reported
frame time changes.

Note that the UI thread is doing many
things, so it is not reliable to
assume the CompositionTarget.Rendering
event handler runs at a reliable
cadence. The model we use (decoupling
the two threads) means that the UI
thread can be a little behind, since
it is calculating animations for a
future frame time.

Special thanks to Dwayne Need for explaining this to me.

Leave a Comment