C# Control.Invoke（）与其委托调用之间的延迟有多长？

我有一个代码引擎，通过使用waveOutOpen和waveOutWrite API方法连续播放较小的块来播放长的WAV文件。为了在文件播放时更新我的UI，在每个缓冲区播放完成后，我从回调函数调用一个单独的线程（因为您希望在回调函数中执行尽可能少的操作），该线程调用我表单中的方法

该表单包含一个类级别的

EventHandler

，该类处理一个方法，在该方法中我使用新信息更新UI元素。在从waveOutWrite回调函数调用的form方法中，我使用如下Invoke方法：

if (_updatedisplay == null)
{
    // UpdateDisplay contains code to set control properties on the form
    _updatedisplay = new EventHandler(UpdateDisplay);
}
Invoke(_updatedisplay);

每件事都是可行的，但似乎偶尔会有一次UI元素更新的明显滞后或延迟。这很容易看到，因为我使用UpdateDisplay方法来驱动动画，所以延迟显示为“打嗝”，精灵在跳到预期位置之前会冻结一秒钟

在这样的跨线程通信中，有时可能会有很长（可能是10-15毫秒）的延迟吗？如果是这样的话，有什么更好的方法来处理这样的事情

更新：顺便说一句，我肯定不确定

调用

是罪魁祸首。另一种可能是音频块播放结束和回调函数实际被调用之间的延迟

---

更新2：根据

itowlson

的建议，我使用了

System.Diagnostics.Stopwatch

对

Invoke

和方法调用之间的延迟进行基准测试。在1156次测量中，我在0毫秒时得到1146次，在1毫秒时得到8次，在2毫秒时得到2次。我想可以肯定地说，

调用

不是我的罪魁祸首。

是的，可能会有任意长的延迟。Invoke通过向目标控件发送Windows消息来工作，因此只有在目标线程发送消息时才会对其进行处理。如果线程已经在处理一条消息，并且该处理需要时间，那么在线程泵送下一条消息并因此处理调用之前，可能会有相当大的延迟

一个更好的方法可能是打电话给BeginInvoke。这并不能避免UI线程处理消息的潜在延迟，但它可以避免在等待UI线程发送消息时阻止调用线程。但是，在您的场景中，这可能没有帮助，因为听起来是UI线程的繁忙导致了动画中的小故障

---

更新响应您的更新：注意，我在这里说的是可能会有任意长的延迟，而不是会有明显的延迟，或者这肯定是您延迟的原因。10-15Ms对于应用程序花在消息处理中的时间似乎非常长，除非在UI线程上有一些非常密集的事情发生，所以您当然可以考虑其他原因。p> 我刚试过用BeginInvoke，但还是打了个嗝。另外，我在尝试运行一个动画时遇到了同样的问题，从一个高分辨率计时器中回调，但也遇到了同样的问题。我想知道这是否是.Net UI的基本功能？不，它是任何UI的基本功能，至少在Windows中是如此。Windows窗体中的消息架构不是什么新的东西，甚至是C++应用程序在Windows中工作的方式也是一样。如果您试图更新进度条或其他不应跨线程调用的内容。取而代之的是，对进度变量使用互锁写入，UI线程会每隔一定的时间读取进度变量。这听起来好像动画组件在发送消息方面不是一个好公民，但我不太愿意推测这里发生了什么，特别是因为您不确定调用是问题所在。尝试捕获调用BeginInvoke的时间和UpdateDisplay开始执行的时间：这可能有助于确定跨线程调用是否确实是问题所在。（您需要使用高分辨率计时。）好吧，它不是

Invoke

，并且动画每帧的渲染时间不到1ms，所以不是这样。我剩下的两个罪魁祸首是waveOutWrite回调本身的延迟，或者是我的帧速率与屏幕刷新率同步的问题。不幸的是，我对其中任何一个都无能为力。