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 ?
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...
Related
Last week I learned that Silverlight on the Windows Phone uses a "compositor" thread to cache bitmaps and animations and run them independent of the UI thread. This allows animations to run smoothly even if the UI thread becomes blocked.
My question is: why was this introduced only for WP7, and not Silverlight (web) or WPF?
A lot of Microsoft's recent focus has been on Silverlight for Windows Phone 7 (make or break time), so they have added essential features to the phone now that would be in the next version of Silverlight. Basically anything to make the phone look fast/smooth/good.
I heard specific mention of an upcoming feature in Silverlight (browser version) being: "running animation storyboards on a background thread". That was in a recent video (sorry lost the link).
To have the compositor thread specifically run on a GPU requires that the hardware running the software has a GPU and that it is sufficicently powerful for the task.
WP7 devices are the first place that they can guarantee that every piece of hardware running Silverlight has a baseline hardware requirement.
If Silverlight tried to do this it would have to move the compositor on to the CPU if the hardware it was running on didn't have a GPU. If that CPU was a single core then on some machines the underlying code would just have become more complicated for no performance gain.
The compositor (render) thread runs the GPU on Windows Phone 7 devices.
As a resource constrained device, it's necessary to do all the cool animations to have this stuff running on the GPU with bitmap cached images. I would imagine this was an unavoidable design choice for the Windows Phone 7 platform team to accomplish the kind of visuals that are possible on Windows Phone 7 devices.
Sure, perhaps it will also be relevant to do for WPF and Silverlight in general in due course.
So it's not so much about providing another thread to alleviate load from the CPU. It's a thread to manage the GPU. The UI thread runs on the CPU, handling general UI interaction and all other non-GPU code.
I'm using VS 2010 on Windows Server 2003, running on a Dell Inspiron 9400 laptop. VS 2010 runs fine, except for persistent and random screen re-drawing issues. Samples of these are here.
These artifacts occur as the mouse moves over items that highlight on a mouse-over event, while scrolling, and when switching tabs. VS 2008 has non of these issues, so I assume that it is related to VS 2010's use of WPF. Could it be that my video card or driver is not up to the task of rendering WPF? Some other WPF applications (not Silverlight) also have some of these screen repainting problems.
I have tried a variety of settings in System Properties-->Advanced-->Performance Options-->Visual Effects, and in the related "Advanced" tab, Processor Scheduling is adjusted for best performance of programs.
Many thanks for any suggestions!
This has been answered for a while but I just fixed a similar issue with screen artifacting I was receiving in editor views of a MVC3 application. I'm running on a Core i7 3960X 6 core processor, the graphics card is a Radeon HD 6950 2GB. Needless to say, I shouldn't be getting these issues. It looked to be something related to my graphics card because going to Tools > Options and then unselecting "Use hardware graphics acceleration if available" caused the issue to stop occurring -
Visual Studio uses WPF which used the video card alot more than traditional GDI applications, I'd check your card drivers and make sure they're up to date.
I have been playing a bit with Silverlight and try to port my Silverlight 3.0 application to Silverlight 4.0.
My application loads different XAP files and upon a user request create an instance of a Xaml user control and adds it to the main container, in a sort of MEF approach in order I can have an extensible and pluggable application.
The application is pretty huge and to keep acceptable the performances and the initial loading I have built up some helper classes to load in the background all pages and user controls that might be used later on.
On Silverlight 3.0 everything was running smoothly without any problem so far.
Switching to SL 4.0 I have noticed that when the process approaches to create the instances of the user controls the layout freezes unexpectedly for a minute and sometimes for more. Looking at the task manager the memory usage of IE jumps from 50MB to 400MB and sometimes up to 1.5 GB.
If the process won't take that much the layout is rendered properly even though the memory usage is still extremely high. Otherwise everything crashes due to out of memory exception.
Running the same application compiled in SL3, the memory used is about 200MB when all the usercontrols are loaded. Time spent to load the application in SL3 is about 10 seconds, while it takes up to 3 mins in SL4 There are no transparencies, no opacities set, no effects and animations in the layout.
User controls are instantied on the fly and added or removed in the visual tree on purpose when the user switches from one screen to another. The resources are all cleaned properly when a usercontrol is removed from the visual tree to allow the GC to operate in the background.
I may do something wrong but I could not figure out where exactly nail out the source of this problem. As far as I know there is no memory profiler in SL4 that can help me out to find where to look at. But again I could not be updated on new debugging tools available.
UPDATE:
Silverlight 4 Service Release to fix Memory Leaks: http://timheuer.com/blog/archive/2010/09/01/silverlight-service-release-september-2010-gdr1.aspx
Silverlight 4 has known memory leaks and the fix is currently being tested.
Here is a Microsoft Thread about it:
The user "heuertk" is a Microsoft Silverlight Developer....he explains the issues and the status of the fix...
http://forums.silverlight.net/forums/t/171739.aspx
To be honest despite your assertion "The resources are all cleaned properly when a usercontrol is removed from the visual tree" this where I'd start looking. It really does smell of elements of UserControls not being released properly.
This typically occurs when there are long lived (for example static) objects that raise events that more transient objects attach to. If these event handlers aren't detached it leaves these objects hanging around in memory.
I am keep testing and would like to share what I discovered so far.
It might be helpful to understand the behaviors of SL4.
Since it sounded pretty weird the UIThread can take so long to render a bunch of graphic components and considering Microsoft has improved the render pipeline, I have reverted my solution to SL3 but I have kept SL4 installed on my localhost.
The application uses RIA Services and moving back and forth to SL4 means that I have to do some changes in the code as per released documentation.
The application runs extremely smooth more than it was if it is tested with Visual Studio 2008. The memory usage is lower than it was before when SL4 wasn't installed.
As soon as I switch to VS2010 it is a completely different scenario. Memory grows undefinitely, the layout is slow to catch the user interaction and sometimes it freezes as before explained.
I have disabled RIA Services, by using standard Rest service and the process hasn't changed in quality.
In conclusion, considering I will keep testing in order I can finally understand what is really preventing to get the application running in an acceptable mode, I believe the memory issue is due to the debug process of VS 2010 or a combination of VS 2010 and SL4
Just for your info: there is a memory leak when using Silverlight Toolkit Charts in Silverlight 4.0. This is a known bug and Microsoft is working on it.
Silverlight 4 is Leaking everywhere. It Doesn't release memory properly.
I'm maintaing a Windows Forms application which draws map data with overlays. I've been considering a move to WPF for the drawing layer, to take advantage of the graphics card rendering. In the last couple of weeks, however, I've started to have some doubts:
The new release of Evernote uses WPF, and doesn't run on Nvidia Quadro cards.
A WPF transitions demo from WindowsClient.net stopped rendering part-way through the animations on one of our test portables with Intel graphics (and yes, we had the latest Intel drivers).
Stack Overflow questions like this.
With the current Windows Forms codebase I can expect the application to run identically at every installation. WPF is much more dependent on the quality of the graphics card drivers, and I don't have the testing resources for comprehensive coverage.
I'm particularly interested to hear from people who've delivered a WPF application outside their own company or to a mixed population of machines - did hardware and driver specific bugs cause you a significant support burden?
We are facing some issues with the drivers of a specific graphic card vendor. Blue screens, a diagonal pixel displacement and application crashes have been observed. It is possible, however, to turn off the Hardware Acceleration on a per-application basis. Sad but true, this is the current workaround.
As already stated, I hope that the VS2010 release will help to improve the stability. Perhaps one day we'll see lists of WPF related fixes in the release notes of graphic card drivers. Along with the latest fixes for the game engine XYZ.
Our WPF application is running on Windows XP SP2 (minimum) and is ok apart from on some machines, if the application is running and the PC goes into screensave mode it blue screens and crashes the machine. This seems to be graphics card driver version related - some of our users run dual monitors.
We haven't cracked this issue yet.
WPF uses Direct3D for its rendering, falling over to software if necessary. My best guess is that some drivers say that they support something in hardware but really don't handle it properly, and that is when we see these incompatibility issues.
The answer to your question depends on how willing you are to have less compatibility with machines than your current codebase has. If you've ever visited support forums for PC games you see all sorts of threads about graphics problems. As most PC's are going to be more and more compatible with Vista/Win7 and therefore support D3D9/10, the issues should lessen. The real question is if the tradeoff for you is worth it.
My own experience deploying a WPF app, I had issues with the mediaelement not working the same on two very similar PC's. But the video subsystem is a different can of worms anyway. Otherwise it was fine but I wasn't doing anything special graphically, just standard xaml.
Kevin Hoffman this morning reports that:
When put under a virtual machine
running Windows 7, VS2010 fails to
render things, borders disappear,
windows become unusable and the
experience is downright awful. On the
other hand, when you run VS2010 "bare
metal" with no virtualization between
it and your video card, everything is
beautiful and all works well.
What about a virtual machine would cause VS2010's WPF to render poorly?
WPF renders stuff on a Direct3D surface. It's able to take advantage of hardware acceleration features provided by graphics cards to improve performance. Under VMs, these features might be unavailable.
I haven't tried VS2010 specifically yet, but you may be hitting a known issue with WPF apps in VMs. Try disabling hardware acceleration as described here:
http://msdn.microsoft.com/en-us/library/aa970912.aspx
Our custom WPF app running on a VM had similar performance problems, and that fixed it for us.
As Mehrdad says, Virtual Machines don't really virtualize 3D hardware (there is some work being done in this area by VMWare, but it's only older versions of DirectX I think) and WPF utilizes the GPU to render more efficiently, thus it has to use software to render in a virtual machine and that is significantly slower.
If you have a multi-core machine, and you're using a Virtual Machine manager that supports giving VM's multiple cores, then you might consider adding more cores to the VM to better utilize CPU resources, or use Kevin's Registry changes.
VS2010 isn't a finished product and it ties in quite heavily with various elements of the system's native GUI interfaces (which, in Windows 7, also not a finished product, these are not fully cultivated). It's not entirely surprising that two betas running in a virtualised environment would have issues. As stated, this is liable to be an Aero issue, which ties in heavily with DirectX's hardware rendering. These issues might not occur under classic assuming Win7 has that.
I'm using Windows 7 + VS 2010 + WPF and everything is fine, however I'm using VMWare Fusion with hardware acceleration on.