How long is the delay between Control.Invoke () and its delegate call?

Question

I have a code engine that plays long WAV files, playing small pieces in a row using the waveOutOpen and waveOutWrite API methods. To update my user interface when playing a file, from the callback function, when each buffer finishes playing, I call a separate thread (because you want to make as little as possible inside the callback function), which calls the method in my form.

The form contains an EventHandler class level that handles a method in which I update user interface elements with new information. In the form method called from the waveOutWrite callback function, I use the Invoke method as follows:

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

Everything works, but it seems that from time to time there is a noticeable lag or delay in updating the interface elements. This is easy to see because I use the UpdateDisplay method for animation, so delays appear as “hiccups,” where the sprite freezes for a split second before it moves to its expected position.

Is it possible that sometimes there is a long (maybe 10-15 milliseconds) delay associated with cross-connection? If so, what is the best way to deal with something like this?

Update : by the way, I'm definitely not sure if Invoke here. Another possibility is the lag between when the piece of sound ends and when the callback function is actually called.

Update 2 : for itowlson , I used System.Diagnostics.Stopwatch to compare the lag between Invoke and method invocation. From 1156 measurements, I got 1146 at 0ms, 8 at 1 ms and 2 at 2 ms. I think it's safe to say that Invoke is not my culprit here.

Answer 1

Yes, there may be an arbitrarily long delay. Invoke works by sending a Windows message to the target control, so it will only be processed when the target thread is sending messages. If the thread is already processing the message, and this processing takes time, then there may be a noticeable delay before the thread scans the next message and thereby processes Invoke.

A better way would be to call BeginInvoke. This does not prevent a potential delay in processing the user interface thread, but prevents the blocking of your calling thread while waiting for the user interface thread to download messages. However, this may not help in your scenario when it sounds like a busy UI thread that causes the animation to crash.

Update in response to your update: Note. All I am saying here is that there may be an arbitrarily long delay, and not that there will be a noticeable delay or that this is definitely the reason for your delay. 10-15 ms, it seems, an unusually long time when the application is spent on processing messages, if something really intense is not happening in the user interface stream, so of course, it is wise for you to consider alternative reasons!