Getting around the WPF rendering bottleneck

I love to make efficient apps and often look to concurrency and multithreading to improve application responsiveness and such, but lately my attempts always seem to be blocked by WPF's single-threadedness. No matter how efficient and parallel my code is, WPF seems to continually stall my UI and make my app look incredibly unresponsive--sometimes waiting for a window to render can take precious seconds (where even the mouse cursor won't move). I find this frustrating as it seems there's nothing I can do to speed things up.

My question, then, is is there anything I can do to improve responsiveness in my WPF app? My windows tend to be rather complex in style and composition, and I am already using virtualizing StackPanels.

To illustrate my problem: I have a text box that acts as a search box, and I want results displayed on the fly as the user types (each result is encapsulated in a UserControl and displayed in an ItemsControl). I am using background threads to perform the search. The problem is, it's when WPF renders the results of the search that completely stalls the UI so that typing is frozen for seconds at a time while WPF churns away, making the whole "results as you type" thing not very viable.

Is there any way I can avoid having the UI thread stall while WPF is rendering?

Given that you're already using threads to fetch data I can only surmise that the data sets being returned are large enough to be causing the slowdown. (Could you provide some metrics there?) For example, you may have a thread fetching an array of names but if the result is in the many, many thousands then there will definitely be a performance hit when you bind.

The only thing strategy I can think of is to narrow the results coming back from your thread (using the TOP sql clause if you're doing Sql Server) or, if you really need to display all the data that is coming back, break up the stream into chunks so that the UI does not have to render as much data all at once. The latter option would be rather complex and might call for creating from scratch or at least overriding the UI controls.

The number of results is in the hundreds, say 300. On top of that I'm using VirtualizingStackPanel so it's only rendering maybe a dozen or two at a time, yet it's still slow enough to get in the way of the user typing.

chaiguy 2010-08-18 00:58:25

Ouch, that's terrible. Which version of the framework. If you're not using 4.0, it's touted as having massive performance improvements. Also, if it's not the rendering then it must be the binding that's causing the slowdown.

Paul Sasik 2010-08-18 01:08:50

I am using 4.0, and I did notice some improvements initially, but not enough to get over this problem. Now I'm not sure what's causing the problems, though I am using a *lot* of binding.

chaiguy 2010-08-18 01:39:32

If you're rebinding the entire view when the model changes perhaps you could try binding with a finer grained approach? That's probably a lot of refactoring but i don't see how else to improve the situation.

Paul Sasik 2010-08-18 01:48:35

I suppose I could move some of the binding logic into the class itself and perform it manually at initialization and/or when certain dependencies change. This seems ironic to me though as I thought binding was supposed to save me from all that! :)

chaiguy 2010-08-18 02:42:44

MS also sets up their IDEs so you can drag and drop your way into a prototype within minutes but implementing the real solution is another story. RAD didn't work out so well (whatever happened to RAD?) and it's possible that you're seeing drawbacks to MVVM. In other words, the technology is not quite up to hype. Though I do think XAML is the way of the future. The excesive binding might not be.

Paul Sasik 2010-08-18 03:19:15

ansaurus

tags:

views:

answers:

Getting around the WPF rendering bottleneck

related questions