9

I don't have a specific scenario in mind, but this question just crossed my mind while I was thinking of scenarios where I may want to use a Timer over a DispatcherTimer.

In the scenario where I have to perform come computationally intensive task whenever a timer event fires, and then make minor modifications to UI, would it be better in terms of performance to:

  1. use a regular Timer and then use the application's Dispatcher to change the UI
  2. use a DispatcherTimer (and possibly do my computationally intensive work in some async background worker if necessary).

My guess is that keeping the UI thread unblocked for as long as possible will enhance the user experience. If this is advisable, Are there any catches that I should be aware of in such a scenario?

EDIT:

I get the feeling my question was not clear enough, so I'm going to try and add a concrete, albeit made-up example.

Let's say I have to read a large file every 2 minutes, and when I'm done, I have to add an item to a ListBox. Let's say reading/processing the file takes 10-15 seconds, during which I do no UI work. What would be the best approach for something like this?

K Mehta
  • 10,323
  • 4
  • 46
  • 76

6 Answers6

5

Main point:

to perform come computationally intensive task

This would indicate not using the DispatcherTimer. It mainly exists to perform small tasks on the main thread and avoid creating another thread.

If you use a DispatcherTimer to start a Backgroundworker you're circumventing its main purpose.

So just use a regular Timer here.

H H
  • 263,252
  • 30
  • 330
  • 514
  • Is there anything I should be aware of when using a regular Timer? I recollect reading somewhere that UI elements may need to be locked, but I'm not sure if this is necessary/true. – K Mehta Dec 04 '11 at 10:57
  • 1
    Yes, you will need Dispatcher.Invoke() when updating the GUI. As usual. – H H Dec 04 '11 at 11:01
2

After some more research and analysis, I've come to the conclusion that a regular timer works best in my made-up example. So far, I haven't had to look out for anything specific that would cause potential problems in my code. Having said that, good coding practices never hurt!

K Mehta
  • 10,323
  • 4
  • 46
  • 76
1

Comparing Timer with DispatcherTimer Some answers posted here are more specific to your question but I think this link offers some general information and advice.

Community
  • 1
  • 1
Ashwin Raman
  • 21
  • 5
1

  • Timer generates recurring events in an application

  • DispatcherTimer is a timer that is integrated into the Dispatcher queue which is processed at a specified interval of time and at a specified priority.

Timers are not guaranteed to execute exactly when the time interval occurs, but are guaranteed not to execute before the time interval occurs. This is because DispatcherTimer operations are placed on the Dispatcher queue like other operations. When the DispatcherTimer operation executes, it is dependent of the other jobs in the queue and their priorities.

If a Timer is used in a WPF application, it is worth noting that the Timer runs on a different thread then the user interface (UI) thread. In order to access objects on the user interface (UI) thread, it is necessary to post the operation onto the Dispatcher of the user interface (UI) thread using Invoke or BeginInvoke. Reasons for using a DispatcherTimer opposed to a Timer are that the DispatcherTimer runs on the same thread as the Dispatcher and a DispatcherPriority can be set.

Glory Raj
  • 17,397
  • 27
  • 100
  • 203
  • 1
    Maybe I should clarify my question, but I already know that a timer runs on a separate thread, and that a Dispatcher is required to touch the UI in this case. I was more curious about when it may be worth using a Timer in a WPF application even when I have to touch the UI. – K Mehta Dec 04 '11 at 09:43
0

If you want to change a scalar (not a collection) value binded to UI element, you can do it not only from UI thread (e.g. from Timer delegate). And in this case you don't need to use Dispatcher.Invoke/BeginInvoke.

Denis
  • 1
0

Another option is to use DispatcherTimer with creating BackgroundWorker class instance on each timer iteration. It also frees you from using Dispatcher.Invoke/BeginInvoke in many cases.

Denis
  • 1
  • I'm aware of my options :). I'm looking for some insight into what the *ideal* option would be. – K Mehta Dec 04 '11 at 10:13