WPF rendering freeze

Question

I'm experiencing a GUI freeze problem, related to hard vs. software UI rendering.

The context : 2 WPF apps (.NET 3.5 SP1) running on a dual-display XP Embedded machine (DirectX 9.0c).

At some point, one of these app freezes. But only the rendering : the GUI stays active (message pump is active, the application is responsive), but the rendering is not done. The freeze can last seconds or forever. The 2nd app keeps running normally. The bug occurs only in a dual-display configuration, the 2nd app being a kind of catalyst (more memory and CPU usage...)

Using Perforator, I see that Video Memory Usage is continuously going up & down in spikes (cf : screenshot). During that time, one native thread is consuming 100% of a CPU (the stack-trace involves WPFgfx, DirectX, GDI, and video driver)

Usually, when the app unfreeze, it's fully software rendered (purple tint with Perforator). Also, de-activating hardware rendering unfreeze the app.

My conclusion, so far, is that I'm facing an out of video memory (as described at point #14 in this post), with an attempt to fallback to software rendering, but there is a loop somewhere trying again in hardware mode.

Am i right ? Would it be more a WPF problem, or a video driver problem ? or even DirectX ? Are there some parameters I can tune around this ?

Frech

Have you found a work-around or solution for this? I'm experiencing a very similar problem. I'm forced into .NET 3.5 for my app. – Verrucose

I'm experiencing a similar issue. Does the freeze occur in the same app each time? Have you found a way to reproduce the issue? Does it occur on more than one machine? – Atharvaveda

Not a duplicate, but you might be interested: when you see wpfgfx freezing, the problem may be in WPF FontCache, please see stackoverflow.com/questions/25822683 – Rosemare

Answer 1

Am i right ? Would it be more a WPF problem, or a video driver problem ? or even DirectX ? Are there some parameters I can tune around this ?

This sounds like a driver issue. I would start with seeing if there are driver updates. The best option might just be to disable hardware acceleration altogether, as WPF (on XP especially) really relies on the graphics drivers.

Visual Studio 2010 sp1 disabled hardware acceleration for itself on XP for exactly this reason...

Quibbling

Hi Reed, Do you have a link to any documentation regarding the decision to disable hardware acceleration in VS2010 on xp? Did disabling the the acceleration fix these problems? Is there a listing of driver versions that either exhibit or do not exhibit the problem? – Atharvaveda

@LukeN: There were a lot of blog posts. ie: blogs.msdn.com/b/jasonz/archive/2011/03/03/… (Good description here: blogs.msdn.com/b/jasonz/archive/2011/03/03/…) – Quibbling

In addition, see connect: connect.microsoft.com/VisualStudio/feedback/details/559846/… and connect.microsoft.com/VisualStudio/feedback/details/575376/… as well as the Graphics Rendering page for WPF: msdn.microsoft.com/en-us/library/aa970912.aspx – Quibbling

Excellent! Do you have any idea which versions of the ati or nvidia drivers these issues were resolved in? Obviously disabling h/w acceleration is an option, but our framerate is becomes barely acceptable when we do so instead of silky smooth. – Atharvaveda

@LukeN: Unfortunately, no. It's very specific to hardware+driver combos - sometimes, newer drivers with older hardware exhibit problems. That being said, most of the newest drivers seem to work reasonably well on Vista+W7, with most hardware, from my experience. – Quibbling

It turns out that we appear to have two issues. Disabling h/w acceleration looks like it has helped with one. The other issue we have experienced looks like it is related to problems with an embedded video control social.msdn.microsoft.com/forums/en-US/…. – Atharvaveda