I have developed WPF Application. In that application iam loading 200mb photos to the listbox.After that Iam adding those images to canvas.While adding photos to canvas after sometime (i.e; after adding 10mb images)iam getting Some error like ----
*****The CLR has been unable to transition from COM context 0x10b46f0 to COM context 0x10b4860 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.*****
Is there any way to increase the performance of my application. I need a solution for this problem.
Any Suggestions for this.
Don't load all 200 mb of photos into the listbox all at once on your UI thread. Will the user be looking at 200 mb all at once? It'll take some work on your part, but you're going to need to do some delayed loading of the images from a background thread.
Take a look at this article (Advanced Techniques To Avoid And Detect Deadlocks In .NET Apps), it may help.
This looks like two questions, the first is that you are loading images in a background thread, but not doing it correctly; thus, the COM error. Double check that you are have a STAThread application and that the image loading thread is not interacting with the WPF dispatch thread incorrectly. Here's a discussion MTA vs. STA; however, WPF needs STA, and it's a loosing battle to fight it.
The second question seems to be how should one do this; that is, loading a bunch of images for display. I would look into using a lazy data binding of the ListView and let the virtualizing presenter that's built into is manage the loading/display of the images.
Here's some docs on using a view-model. The viewmodel could coordinate the image load and provide the ListView with a binding source that would automatically get the application working.
A simpler alternative might be to start up a background thread and load the images into an ObservableCollection<>, bind that to the ListView and let the framework deal with the display.
I second what Greg D said, loading 200mb of images sounds like a recipe for problems.
Related
I have a standalone WPF application running on .NET 3.5. Every so often, the display simply freezes up for several seconds. This is most noticeable on screens where something is being updated often. Here is a video showing the problem.
While the display is frozen, the interface remains responsive (video).
I've come across some other posts with similar problems who attributed it to a SW/HW rendering issue. To be safe, I disabled HW rendering altogether, but still have the problem.
I ran a file monitor during the freezes to see if there is some extraordinary file access or activity going on, but nothing is out of the ordinary.
Final note: The target platform is a small touch-screen panel PC without much memory or horsepower (512 MB). I only see this issue on the target, never on my development PC, which has much more in the way of resources.
UPDATE
I thought I had fixed the issue by removing some animation code, but it did not work. I am still encountering the problem and I'm at the end of my rope.
Here's some more things I've tried:
Upgraded to .NET 4.0. Same behavior.
Added debug code to all methods that may be invoked via DispatcherTimer (which are called on the UI thread) to make sure none of them are holding up the UI.
I'm really stumped here and have added a bounty. As I mentioned, the problem only occurs on the target PC (link).
I tend to suspect either .NET GC or the OS swapfile when this kind of behavior shows up.
For the former, you could try the .NET performance counters to monitor for suspect activity.
If the device has a swap file, you can disable it and see if the behavior changes.
As others have said, a profiler (or some what of isolating what condition is inducing the delay - even just attaching and breaking the debugger when it occurs) would be a good way to get more information.
Did you tried to profile the application on the tested system? Using a memory and/or performance profiler?
You could get some good informations out of this type of test : some .Net profilers
And here's one for WPF : WPF profiler from microsoft
The culprit was the following method call:
new HwndSource(new HwndSourceParameters());
This was added to my application because it patched a memory leak problem in .NET 3.5. This work-around can be found here. If I remove this call, the rendering issues go away.
I took out the call and fixed the memory leak in another way (removing storyboard animation and using code behind instead)
I have a WPF application in which I'm using SoundPlayer to play several short sounds such as keyboard clicks. Sometimes, seemingly at random, the sounds will stop playing. When I navigate away from the page the sounds will then play all at once in one screeching playback.
My question is, are there any obvious reasons as to why this would happen?
I've tried several things but because I can't consistently reproduce the issue it's hard to find the cause. The sounds are used throughout the application, so I load them in app.xaml.cs into an application scoped static collection. I call SoundPlayer.Load() to ensure they're loaded into memory straight away.
Like I said, this never stops working completely. The play backs seem to pile up until navigating to another page where they all play at once.
One other thing that may have an impact is that I am displaying a webcam feed in the application. The webcam feed is loaded using the DirectShow.NET library. I'm not sure if loading graphs can have any adverse effect on the playback of sound.
I suppose the web cam is updating a UI element which will cause the UI thread to be pretty busy, in that case you probably do not want to use SoundPlayer.PlaySync() or SoundPlayer.Load which both block the current thread.
Instead try SoundPlayer.LoadAsync() and SoundPlayer.Play() which use a separate thread.
I'm trying to provide a live preview of XPS documents without hanging my UI thread. Opening the document is fast enough, but when I call GetFixedDocumentSequence(), my UI becomes unresponsive for several seconds while the document chugs away.
// creating the doc is fine (0.005 seconds)
XpsDocument doc=new XpsDocument("BigFile.xps",FileAccess.Read);
// this hangs the UI for several seconds
FixedDocumentSequence seq=XpsDocument.GetFixedDocumentSequence();
// Once I have the sequence, GetPageAsync lets me pull out pages without breaking the UI
// ....
The obvious solution is to open the document on a worker thread, but the FixedDocumentSequence is tied to the thread that created it, so I can't access it from the UI thread, and if I try to call GetPageAsync from the worker thread I get an exception because DocumentPages contain visuals.
The only thing I can think of is to create the document on a seperate UI thread, break the document into pages, and then save those pages as XPS files that the UI thread opens. But that seems like a horribly complex solution. Does anyone know if there is an alternative way to getting the DocumentPages that does not rely on the FixedDocumentSequence?
There is a simple solution. It's called multi-threaded UI and it helps you to do everything as you would do, but have two UI threads instead of one. It means that your XPS can load on a seperate UI thread without any problem. I've implemented it myself in the past, and it's good.
http://blogs.msdn.com/b/dwayneneed/archive/2007/04/26/multithreaded-ui-hostvisual.aspx
I did nice winforms 2.0 application and it's working great and customers are still happy but unfortunatelly I cannot solve one issue. The problem is that after using app for a couple of hours, gdi user handles number is rising and rising and finally process cannot allocate more objects and app crashes...
I'm not doing anything fancy, it's regular app, a few forms, a few more modal forms, a few datagridviews and a lot tablelayoutpanels where I'm adding a lot labels and textboxes.
My questions are:
are there any "recommended-practises"
concerning adding/removing regular system
controls on forms at runtime (dgv/tlp)
how to detect system handles'
leaks - preferably using visual
studio and a kind of free plugin
(profiler?)
Detecting graphics and window handle leaks is very difficult. As to a particular strategy for finding them at runtime, I can't suggest anything (though I'd love to hear someone else's!).
As for preventing them, here are a couple of reminders:
While the Control class's finalizer will call Dispose(), this is non-deterministic. You are not guaranteed that ANY object will EVER get finalized by the garbage collector. It's likely that it will, but it's not a guarantee.
In keeping with the above, Forms are an exception. When a Form is shown in a NON-MODAL way (meaning through Show(), NOT ShowDialog()), then when the Form closes it will deterministically call Dispose(). Forms that are shown through ShowDialog() must have Dispose() called manually in order to deterministically clean up the control handle.
Keeping those two things in mind, the most important thing that you can do is to ensure that you always call Dispose() on any object that you explicitly create that implements IDisposable. This INCLUDES Forms, Controls, Graphics objects, even the graphics helper classes like Pen and Brush. All of those classes implement IDisposable, and all of them need to be disposed of as soon as you no longer need them.
Try to cache your graphics utility classes, assuming you're using some. While a Pen and a Brush are fairly lightweight to create, they do take up handles and need to be disposed of when you're finished. Rather than creating them all the time, create a cache manager that allows you to pass in the parameters that you would use in the constructor for those objects and keep that object around. Repeated calls with the same parameters should still only use one single instance. You can then flush your cache on a periodic basis or at specific places in your application if you know where those would be.
Following those guidelines will greatly reduce--if not eliminate--your handle leaks.
I find that using the Task Manager with the GDI Objects column visible essential to finding such leaks. You can target specific areas by breaking before the call, make a note of the GDI objects, then break after the suspect call to determine if the objects are being released properly.
The source code for two useful GDI leak tracking tools can be found here: link text
I have used it successfully on many Visual Studio C++ projects. I am not sure whether I work with .NET as well.
We have a MFC 8 application compiled with /CLR that contains a larger amount of Windows Forms UserControls which again contain WPF user controls using ElementHost. Due to the architecture of our software we can not use HwndHost directly. We observed an extremely strange behavior here that we can not make any sense of:
When the CPU load is very high during startup of the application and there are a lot live of ElementHost instances, the whole property engine completely stops working. For example animations that usually just work fine now never update the values of the bound properties, they just stay at some random value after startup. When I set a property that is not bound to anything the value is correctly stored in the dependency property (calling the getter returns the new value) but the visual representation never reflects that. I set the background to red but the background color does not change.
We tested this on a lot of different machines all running Windows XP SP2 and it is pretty reproducible.
The funny thing here is, that there is in fact one situation where the bound properties actually pickup a new value from the animation and the visual gets updated based on the property values. It is when I resize the ElementHost or when I hide and reshow the parent native control. As soon as I do this, properties that are bound to an animation pickup a new value and the visuals rerender based on the new property values - but just once - if I want to see another update I have to resize the ElementHost.
Do you have any explanation of what could be happening here or how I could approach this problem to find it out? What can I do to debug this? Is there a way I can get more information about what WPF actually does or where WPF might have crashed? To me it currently seems like a bug in WPF itself since it only happens at high CPU load at startup.
I don't do any work with those techs, so I can't really speak to that. However, to me it sounds like some kind of deadlock is occurring in your code which is blocking calls to redraw() (or its equivalent). Resizing the window will force a redraw, but your normal mechanism for telling it to redraw when you've changed something might be blocked.
Is it possible you have a race condition in your code somewhere? On a lightly-loaded system things might happen in the correct order, but on the heavily loaded one the timing might be different. Perhaps that's triggering a deadlock in your code?
If you can attach a debugger, take a look at the threads that are running. If you can see what each thread is waiting on and what else it holds locks on (You can do this with Java, not sure about your app) that might help you determine where it's dying.
There is no detail on how you load your data on startup... If you haven't done it yet, consider using Dispatcher.BeginInvoke (with a priority lower than render) or a BackgroundWorker
Here is a post on how to do this!
PS. Just be careful if your objects that you bind to is an ObservableCollection<>... Read more about the issues I had doing this here
Most of the time, select isn't broken (as the saying goes).
It does sound very much like some kind of race or deadlock as #Herms suggests.
You could of course check MSDN for known bugs. Depending on what your code is like, when I'm really stuck with a bug I find that removing chunks of code until you're left with a minimal test case usually helps.
Nothing strange happens in your application. Dependency system "stops working" because of the fact, that UI thread, all the system relies to is busy. It's all about priorities for different Disparcher objects. I can consider you to use background processes doe for prolong operations, while all synchronization done in UI thread.
Also, you can play with task prioritization (DispatcherPriority enum as first parameter of Invoke/BeginInvoke methods)
Another tip, can help you is to implement DoEvent pattern, known from WinForms (to process messages in windows queue)
To summarize, you should remember, that you're working in STA. Also, when you're using ElementHost in Windows XP, you actually remove hardware acceleration. Try to use .NET 3.5 SP1 to fix it somehow, but still you have to leave CPU for rendering and dispatching things.