...or...
"What evil in the depths of WPF have I awoken?"
I'm creating a Canvas on a background thread and rendering it to a bitmap. I've had this working in production code for over a year now without problems. I do the following:
- create a Canvas object
- create a new NameScope object
- assign that NameScope to the Canvas
- draw whatever I want on the Canvas
- call canvas.Measure() with the Canvas's size
- call canvas.Arrage() with the Canvas's available rect
- call canvas.UpdateLayout()
- render the Canvas
In the draw step, I have always just called canvas.Children.Add() to put UIElements onto the Canvas. This has always worked.
Now, for some inexplicable reason, in one specific case in the application I'm working on, the call to canvas.Children.Add() hangs indefinetely, blocking my background thread. I can't think of anything I'm doing differently between the code that has been working for over a year, and this one specific case.
Can anyone suggest possible reasons why a call to canvas.Children.Add() would hang like this?
Edit: The background thread is an STA thread (the background thread processing model was put in place because I couldn't process images using WPF on a MTA thread), so the thread apartment model shouldn't be the culprit.
Edit #2: While I understand why people are suggesting I try Dispatcher.BeginInvoke() from my background thread, I don't like that option for two reasons:
- I want my background thread processing to be synchronous on that thread. My background thread has a queue that other threads submit image jobs to, and my background thread processes each job as it gets to them. Using Dispatcher.BeginInvoke() adds another layer of complexity that I'd rather avoid.
- I've never needed to until now. Doing this background processing synchronously on my background thread has just plain worked. I'm trying to determine what could possibly be different about this bizarre edge case that causes this code to not work. If I can't get it to work, I'll end up rewriting this processing code without WPF, which I'd also rather avoid.