The issue here is a bit abstract. We all know, for a background thread to update some UI element.
Dispatcher.Invoke()
is the only option (Is it?). However, Dispatcher.Invoke() in itself delegates the update task to the UI thread. Considering scenarios where:
- A background thread too often updates a UI.
- Tens of thread update the same UI.
The Dispatcher object would keep on delegating the update task to the UI thread and the UI thread may go slow. What can be a possible solution? How could we solve such an issue in Windows Forms where the threading model was very similar to that of WPF? Does WPF provide any other threading technique?
regards,
First of all why there is need to update UI that frequent that human eye will not notice, ideally, even if any progress is updated with a gap of a second, it is acceptable. For example if you are writing a file and you are probably writing 4K bytes every 30 milliseconds, human eye will not notice and we dont care about performance on screen in milliseconds.
Not only you will make UI thread busy, but Dispatcher.Invoke will also block your other thread till the execution is finished, Dispatcher.BeginInvoke will not block your other thread.
UI Thread will probably finish updates in few milliseconds if its just updating few labels or progress on screen.
Neither WPF nor any other platform can provide any better way because UI is a very complex and allowing access from multiple threads can lead to deadlocks so often that app may become non-responsive. This is the reason, every platform, be it java, objective-c or any UI framework, will need you to update UI only in UI’s creator thread.
However, there is a way in WPF to also create multiple UI threads per window, but its quite complex as well. Games etc use something called double buffering, where they work on one buffer in background in separate thread, while previous buffer is still being updated on screen.