Reputation: 1350
MY ViewModel class contains two string properties (Filename and ThumbnailPath), and its DataTemplate contains a Label and an Image, bound to these properties.
void bw_DoWork (object sender, DoWorkEventArgs e) {
List<string> files = e.Argument as List<string>;
FileInfo fi; int percent;
for (int i = 0; i < files.Count; i++) {
FileViewModel newItem = new FileViewModel(files[i]);
fi = new FileInfo(files[i]);
percent = i / files.Count * 100;
bwImportBrowserItems.ReportProgress(percent, newItem);
}
}
void bw_ProgressChanged (object sender, ProgressChangedEventArgs e) {
this.observableCollection.Add(e.UserState as FileViewModel);
}
Typical behavior for a typical number of items (30-50): UI freezes for about 2-3 seconds; around a half of the items is displayed; UI freezes again for a shorter time and the rest is added.
Now I understand it's not the best idea to call UI updates from a loop - I figured the calls come so frequently the UI doesn't have time to respond to them, that's why we see the UI being updated "in groups", leaving it unresponsive in the meantime.
I tried adding Thread.Sleep(500)
as the last line of the loop. This helped me illustrate that everything works as it should, because with this slowdown, the items were being added nicely one after another without any nonresponsiveness.
So I tried different sleep values and settled for Thread.Sleep(25)
. This is not ideal but quite acceptable and comes pretty close to what it should look like.
I'd like to ask if the Thread.Sleep is a common workaround in situations like these, and also what is the general solution people go with in this situation: to update an UI collection from a background loop without ANY unresponsiveness at all. I've also come up with some ideas and I'd appreciate your comments.
Ideas I can think of:
Upvotes: 1
Views: 904
Reputation: 273274
if the Thread.Sleep is a common workaround in situations like these
Consider it a last resort. You are increasing the total processing time (not CPU load).
1) Don't ReportProgress so often - limit it to 10 times, or to every 10 new items.
That is the basic idea. Collect new Items and dispatch a List through ReportProgess. Tune the size of the list.
2) Don't do it in a loop.
Possible, but your 1-item per Bgw looks a lot slower. It might even show the same symptoms.
3) Decouple through a ConcurrentQueue. You can let DoWork fill a Queue and a Dispatcher.Timer could empty it. Also try to process batches with that timer. You can tune the priority of the timer and the batch size.
Upvotes: 1