Я измеряю время между кадрами в простой анимации WPF.Perforator говорит, что приложение работает со скоростью ~ 60 кадров в секунду, поэтому я ожидал, что время между кадрами составит ~ 16,6 мс с небольшим отклонением.
public MainWindow()
{
...
CompositionTarget.Rendering += Rendering;
}
List<long> FrameDurations = new List<long>();
private long PreviousFrameTime = 0;
private void Rendering(object o, EventArgs args)
{
FrameDurations.Add(DateTime.Now.Ticks - PreviousFrameTime);
PreviousFrameTime = DateTime.Now.Ticks;
}
Меня удивили две вещи:
- Время междукадры довольно нерегулярные
- Время между кадрами составляет ~ 8 мс.Я ожидал, что частота обновления монитора установит нижнюю границу времени между кадрами (т. Е. 60 Гц = 16,6 мс между каждым кадром, а все, что быстрее, не имеет смысла).

Y - время между кадрами в тиках (10000 тиков = 1 мс)X - Количество кадров
Возможные факторы смешения
- Неточность таймера
- Если CompositionTarget.Rendering на самом деле не коррелирует с отрисовкой одного кадра
Проект, который я использую: SimpleWindow.zip
=== Редактировать
Маркус указал, что я мог бы использоватьRenderingEventArgs.RenderingTime.Ticks вместо DateTime.Now.Ticks.Я повторил пробег и получил совсем другие результаты.Единственная разница заключается в методе синхронизации:
DateTime.Now.Ticks

RenderingEventArgs.RenderingTime.Ticks

Данные из RenderingEventArgs позволили получить данные, намного более близкие к ожидаемому 16,6 мс / кадр, и они согласованы.
- Я не уверен, почему DateTime.Now и RenderingEventArgs будут генерировать такие очень разные данные.
- Предполагая, что RenderingEventArgs выдает правильные времена, это все еще немного смущает, что эти времена не являютсяожидаемые 16,6 мс.
Если дисплей обновляется каждые 16,6 мс, а WPF обновляется каждые 14,9 мс, мы можем ожидать состояние гонки, которое может привести к разрыву.То есть примерно каждый 10-й кадр WPF будет пытаться записать свое изображение, в то время как дисплей пытается прочитать изображение.