Can you show me your code to create D3D device? do you create Reference or WARP device?

I'm afraid I can only offer a bit of guessing, but maybe it helps. First of all taskmgr reportedly isn't quite the best tool to make these assessments and I've often seen the advice to use resmon instead. Next up .NET tends to be a bit more liberal with how it reserves space for processes, so as long as you don't see a steady increase in memory usage you shouldn't get too concerned about it just yet.

Getting to the 6% processor usage, that doesn't seem too bad. I obviously don't know what your code is doing exactly, or how much better the C++ version is doing, but as an overgeneralized blanket statement, 6% usage sounds fair enough for 256 draw calls. Draw calls take processor usage (more info here) and considering the old rule of thumb (so outdated and unreliable!) for SM2 hardware was that about 750 draw calls should be your upper bound, it's doing pretty well.

As for the system getting slow, I doubt it has anything to do with the overall performance characteristics of your program, since the memory & processor usage shouldn't be taxing your system. Have you tried running the app with the DirectX debug runtimes to see if anything is going wrong under the hood? If so, that might be an explaination why the system graphics are acting up. Edit - I only just now considered your locks & mutexes... You aren't using multiple threads to access your device-bound resources are you? I always found that to be just asking for trouble but YMMV [smile]

I'm see 2 possibilities:
1) Game1.Instance.GraphicsDevice.VertexDeclaration = vDeclaration;
try set this only once and change if need

2) What exacly does modelLock.WaitOne() ?

Quote:Original post by Plerion
But the UI textures get loaded from different threads.

This *might* be causing the problem, or at least adding to it. I haven't messed with multithreading XNA myself, but in its predecessor Managed DirectX accessing the device (that includes loading textures onto it) from multiple threads was quite the can of worms. You could make the device multithreading-enabled with a flag that made device accesses critical sections (like in normal DX9 afaik) but it typically didn't work out too well. I trust the thread access exclusions worked, but I got my share of blue screens where the driver/hardware just didn't like being used by multiple threads.

I don't know if the aforementioned flag is set onto XNA devices or if they have some other means of trying to be thread-safe, but the general advice seems to be to avoid accessing/creating/disposing device-bound resources (textures, meshes, RTs etc) from other threads than the main thread running your game loop. You can still use other threads to load data or operate on a CPU copy of your vertices or textures, but the actual calls to Load/Set/GetData are safest left to the main thread.

Again to be sure, I'm just guessing so don't go throwing your code overboard just on my hunch. If you have the option to load the UI textures from your main thread though, I'd try that to see if it solves your problem. Checking out the debug runtimes however should indeed be the first stop [smile]