Control.Invoke() 与其委托的调用之间的延迟是多长时间？

Question

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

表单包含一个类级别EventHandler，它处理一个方法，在该方法中我使用新信息更新 UI 元素。在从 waveOutWrite 回调函数调用的表单方法中，我使用 Invoke 方法如下：

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

一切正常，但 UI 元素的更新有时会出现明显的滞后或延迟。这很容易看出，因为我使用 UpdateDisplay 方法来驱动动画，因此延迟显示为“打嗝”，精灵在跳到预期位置之前似乎冻结了一瞬间。

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

更新：顺便说一句，我绝对不确定Invoke 是这里的罪魁祸首。另一种可能性是一段音频播放完毕和回调函数实际被调用之间的延迟。

更新 2：根据itowlson 的建议，我使用System.Diagnostics.Stopwatch 来对Invoke 和方法调用之间的延迟进行基准测试。在 1156 次测量中，我在 0 毫秒时得到 1146 次，在 1 毫秒时得到 8 次，在 2 毫秒时得到 2 次。我认为可以肯定地说Invoke 不是我的罪魁祸首。

Answer 1

是的，可以有任意长的延迟。 Invoke 通过向目标控件发送 Windows 消息来工作，因此它只会在目标线程泵送消息时得到处理。如果线程已经在处理一条消息，并且该处理需要时间，那么在线程泵出其下一条消息并因此处理 Invoke 之前可能会有明显的延迟。

更好的方法可能是调用 BeginInvoke。这并不能避免 UI 线程处理消息的潜在延迟，但它可以避免您的调用线程在等待 UI 线程泵送消息时被阻塞。但是，这可能对您的场景没有帮助，因为它听起来像是 UI 线程的忙碌导致动画中出现故障。

更新以响应您的更新：请注意，我在这里要说的是可能会有任意长的延迟，而不是会 em> 是明显的延迟，或者这绝对是您延迟的原因。除非在 UI 线程上发生了真正密集的事情，否则 10 到 15 毫秒对于应用程序来说似乎确实是一个异常长的时间，因此考虑其他原因当然是明智的！