WPF D3DImage loses front buffer - wpf

I am writing code using VS.Net 10 and SlimDX to render 3D content on a D3DImage. It works perfectly under 32 Bit Windows XP. However, after migrating to 64 bit Windows 7 (quad core and 4 GB Ram), the same code does not work any more. The symptom is that after rendering about 10 or 20 times, the D3DImage's IsFrontBufferAvailableChanged event is raised and the property of IsFrontBufferAvailable has a value of false.
I have checked everything I can think of, e.g. RenderCapability.Tier, calling SetBackBuffer, checking the device (in fact it is DeviceEx type) after the front buffer is lost, updating video card driver (nvidia 9500 GT 1G RAM), etc. None of them worked.
One thing that may contribute to the problem is that the image control which uses D3DImage as the source is not created on the GUI thread. I am doing to reduce the work load of the GUI thread to make the application more responsive. Of course, I have been using Dispatcher.Invoke to avoid threading problems. Again, it works perfectly in XP.
Any help is much appreciated. Thank you in advance.

I think there is a x64 version of the slimdx.dll.. if you are using the x32 version, that could be the problem.

Related

High memory usage by a WPF application on VMWare Workstation

I don't want to go too much into detail about functionality, but our application's window resizes when a child control is added to or removed from it. During stress tests performed recently we noticed high peak working set of the application in Windows task manager. The child control was added and removed every 200 ms, and so the window became higher or smaller every so. We performed these tests on VMware Workstation Pro virtual machines (Windows Server 2012, Windows 10).
After at most a couple of hours the application would always report out of memory exceptions, and said window would freeze or disappear. We noticed that the working set was normal after the crash (below 100 MB), but peak working set was always over 1 GB (~1.1 up to ~1.6 GB) at that point.
To find out whether the issue was caused by a bug in our application or not, we decided to create a single-window WPF application with only a timer that changes main window's height every 200 ms. It turned out that this application had the same issue.
The thing is that I couldn't find information concerning similar issues, so I decided to post a question here. How would you explain such behaviour?
Let me also note that:
When the window was minimized, the issue would never occur.
It was hard to reproduce the issue on a host (not a VM), but we happened to observe it there as well (on Windows 8).
We also performed tests on a virtual computer (WMware ESX 5.5). The crash would take place much faster when nobody was looking :-). I mean we connected to a VM from vSphere Client and opened console to start our test app on the OS. Then we switched to another tab of vSphere Client to hide the console. When we returned to it later on (let's say in half an hour), we could observe memory usage history of our test app with a slowly rising slope that fell instantly at the moment the console was displayed.
I will be grateful for any information that could help me understand the reason of this issue. Thank you.
-- EDIT --
I started my test app in two instances on a VM (Windows Server 2012) - both compiled for Any CPU, but one of them had the Prefer 32-bit check box unchecked in Visual Studio. So one started in 32-bit mode and the other in 64-bit mode. The 32-bit version crashed in an hour or so, with peak working set below 150 MB. The 64-bit version kept running. I'm wondering if this might be the way to go...
The following is problem signature of the 32-bit application version:
Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: ResizeStressTest 32.exe
Problem Signature 02: 1.0.0.0
Problem Signature 03: 5762641e
Problem Signature 04: PresentationCore
Problem Signature 05: 4.0.30319.34209
Problem Signature 06: 5348b56b
Problem Signature 07: 283
Problem Signature 08: 13
Problem Signature 09: System.OutOfMemoryException
OS Version: 6.2.9200.2.0.0.272.7
Locale ID: 1031
Additional Information 1: 5861
Additional Information 2: 5861822e1919d7c014bbb064c64908b2
Additional Information 3: 5c1f
Additional Information 4: 5c1f554df00553b422a8baa03b19335a
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=190175
If the online privacy statement is not available, please read our privacy statement offline:
C:\Windows\system32\en-US\erofflps.txt
When I have to track down memory leaks like the one you're describing, I always turn to WinDBG
It's free and it's very effective. It has a very steep learning curve though. It will tell you how many instances of objects are in memory and lead you to what is holding onto their references

Some applications render black frames WPFMediaKit

I have a very weird bug that I just can't understand.
I am currently using the WPFMediaKit library in one of my programs.
When using the library in a near empty new "demo" wpf solution, the image from the USB Camera source is rendered perfectly to the MediaCaptureElement class.
However, using a more complex solution, the same library (without changes), the frame gets rendered black. I can see there is connection to the camera and everything goes well, DirectShow graph is built normally and everything just looks fine, besides the black frames. I can even open the camera properties and see it pushing out frames as usual.
Also, this only happens on Dell E6540 (With an AMD and Intel HD gpu) if it's Windows 7. Windows 8/10 work fine. Have tried a lot of drivers nothing seems to change the output.
I have no clue what to do or what to try.
After many hours and just after deciding to post this question, I found the answer.
The more complex solution, under the AMD Settings application was set to use "High Performance" mode, this mode was automatically enabled on Windows 7 for some reason. Disabling that and setting it to "none" or "lower power" fixed the issue.
Doesn't change the fact that there is an issue with laptops with dedicated AMD GPUs, probably something to do with DirectX/Direct3D which is used to render the frames.

Visual Studio and WPF apps: High CPU usage when logged into other user

Observed behaviour (everything here is on Windows 10):
I run Visual Studio (tried 13 and 15, both behave the same) logged into user A
After starting up, VS takes virtually no CPU time (<1%)
I log into user B, without signing out of A
VS imediately starts using A LOT of CPU time (~25% on my 4 cores with hyper threading)
I can go back and forth between A and B, and it goes back and forth between low and high CPU usage
This is all without any projects or files opened, though it also happens in that case.
I noticed this because I was originally investigating similar behaviour of a WPF application (after a user reported this issue).
While trying to isolate the problem, I found that even a completely new WPF project, with just a single empty window, behaves exactly the same (whether or not run through Visual Studio).
Through profiling and debugging I found that the app seems to spend a huge amount of time handling windows messages.
Specifically I found that it seems to be almost exclusively WM_PAINT messages (we are talking easily hundreds or thousands of messages per second - as many as the CPU can handle it seems).
No other programs I have running (chrome, skype, sublime text, ..) behaves this way.
Has anybody else seen this kind of behaviour?
And/or any ideas what could cause this, or how I could investigate this further?
Naturally, I cannot fix Visual Studio (unless the problem is with my setup somehow) but I hope there is something I can do about my WPF application.
As per Hans Passant's suggestion in the comments, I reported this problem to Microsoft here:
http://connect.microsoft.com/VisualStudio/feedback/details/2390593/wpf-apps-use-a-lot-of-cpu-time-when-logged-into-different-user
As it turns out this indeed seems to have been a bug in WPF, which is fixed in the current version of Windows 10 (probably specifically since the Anniversary Update (version 1607)).
Hence the solution: Make sure to update your OS.

Hardware Acceleration with Multiple Monitors

I grabbed this multi window test code, changed it to use D3DXCreateTeapot instead of D3DXLoadMeshFromX (I couldn't find a teapot.x file), moved the EndScene call below the DrawText call and set NUM_WINDOWS to 1. With those minor changes, the test works and creates two windows, each with its teapot.
I built the test and deployed it in a machine which has an Intel HD Graphics onboard GPU with two heads, each attached to a monitor. Then I moved one window to each monitor, and enlarged both windows to take up about 80% of each monitor space.
With this setup, which is quite close to what my app needs, the window in the secondary monitor always goes too slow. If I swap the windows, it's the same: the one in the secondary monitor starts crawling, and slows down the whole system.
I googled around and some sources (albeit dated) state that only the primary monitor can use hardware acceleration when not in fullscreen mode. I cannot use fullscreen because direct3d9 rendering in my app is done inside a user control embedded in a Winforms GUI.
Is it really impossible to get hardware acceleration for both monitors in windowed mode? The legacy version of our application uses MFC + DirectDraw and manages to perform fast enough, but those are obsolete technologies and we'd abhor going back there.
You have 3 options:
Try many combinations, like: D3DPRESENT_INTERVAL_IMMEDIATE +
(D3DSWAPEFFECT_FLIP or D3DSWAPEFFECT_COPY) +
D3DCREATE_ADAPTERGROUP_DEVICE. Maybe some will offer better
performance.
Render to a surface, convert to a bitmap, and use it like any other bitmap in your form. Something like this
D3DXSaveSurfaceToFileInMemory.
Change your code to DirectX11. You have more options for GDI interaction there. Better rendering behavior. Maybe better drivers.
Some years ago, I made some multiple window code, also multiple device, using DirectX10/11. I can't tell about DirectX9 having this issue, seems absurd to me, but could be your Windows version, or Intel driver.

How to avoid Silverlight application Hanging Problem...?

I developed a Silverlight application with various animations.. While I running my application, it runs better for first 30-45 secs without any problem... After that, It becomes hanging... I am using XP, 32 bit and VS2010 (SL4).. When i reduce my MaxFrameRate value to 10, there is no use.. Still i have the same issue... this is in local as well as in IIS.. So anybody have better idea to overcome this problem... Waiting for your kind help..
Sounds like a memory leak, you need to provide more info. Have you tried using hardware acceleration? http://msdn.microsoft.com/en-us/library/ee309563%28v=vs.95%29.aspx

Resources