We Keep Coding

Why does my WPF UI lag when streaming lots of IP camera's in a single instance, but not when running the same amount of streams in multiple instances?

We have created a WPF application which allows you to livestream multiple IP cameras(Mobotix). This application works fine when connecting it with a few streams. All streams are rendered correctly and without any delay.
However when we try to run the application with more than 20 livestreams, we experience problems with some steams no longer updating and the UI of the WPF application lagging.
We can fix this issue by turning down the quality and/or size of the livestreams. But unfortunately this is not acceptable as the images do not contain enough detail.
After a lot of debugging, and trying with different ways to display the steams, to no avail, we noticed that if we run multiple instances of same application each rendering a limited amount of steams (for example 3 instances with 8 livestreams each), that there are no issues with any of the instances nor the camera streams themselves.
With this information we were wondering why there is a difference with one instance of the application running 24 streams or 3 instances of the same application running 8 streams each.
Does anyone here know what causes this behavior? Is there some sort of memory limitation for each application instance? Or a limitation of some kind in the GUI thread of a WPF application? Maybe there are other things we are failing to see here?
Any help would be highly appreciated!

How to reduce memory consumption when app is minimized for x amount of time

This is a common problem with Windows. Over the years, it's something that I've noticed and it's really aggrevating me to the point where I just don't want to make apps anymore. So I've decided to try and fix it within my own apps.
When I minimize an app (for example, Visual Studio, Windows Explorer, Internet Explorer, Chrome, or any other app ever made) and leave it there for a while, there is a huge delay (of anywhere between 3 to 20 seconds) between the time I click the icon in the taskbar until the time it has reached WindowState.Normal again.
Why is this? Why doesn't Windows suspend processes when they are minimized on the Desktop? And how can I solve this problem within my own apps?
I have thought about using a Timer. Start the timer when I minimize my app, let it run for a while and say, after about 10-15 minutes of it being minimized, if it hasn't been restored yet, start releasing some resources in the hopes of freeing up some memory - which I assume would make the response time quicker so that it doesn't feel like I'm waiting in the ER when I try to un-minimize my app. But I am not sure if a Timer is the right way to deal with this problem, and I'm not even sure if this is the right solution. All I know is that I'm getting sick of this and I need to do something.
Has anybody dealt with this before? Are there any articles out there or is there MSDN documentation that addresses things like this?
How can I better manage resources in my apps so that they don't become so slow when inactive for a little while?
This problem is common to any app. Not just mine.
Edit: I'm not sure what to do. I always make good use of using() whenever something implements IDisposable, and I just don't know how else I can try and free up some resources or speed up the response times.

The symptomes you describe seem to indicate that your machine lacks physical memory. When you minimize an application and activate another, the minimized application has many of its memory pages swapped out to disk. When you activate back the application, pages belonging to other applications are swapped out to disk and the perviously swapped out pages belonging to the application you just activated are swapped into physical memory, taking a long time due to the relatively slowness of the hard drive. Solution: Add more RAM, it's relatively cheap. If your O.S. is 32 bit, you can go up to 4GB. If your O.S. is 64 bit, whatever your motherboard supports is the limit.

how to optimize performance of longlistselector with images on windows phone?

I have a page with a pivot containing about 10 items, each pivot item contains a longlistselector with 30 items each.
Each longlistselector item contains an image.
When I'm browsing the page and I flip to the next pivot item, the app crashes at the 4th pivot item with a memory exception.
Is there anyway to unload undisplayed images in the longlistselector?

i suggest rethinking your app layout, 10 pivot items is a tad too many for normal user navigation, why not have a main page with a longlistselector of "categories" follow by a details page of 30 images.
But if you absolutely have to do it this way, take a look at microsoft's photohub source
I'm using it personally and have no problem loading hundreds of images in a panoramaItem.
Better still if you can afford the time, do a memory profile and look exactly where the bloat is, sometimes it might be some part of your application that is hogging on to the memory.
Last of all, wp itself caches the images automagically, but not everyone likes it this way (i'm sure you don't)
take a look at this:
Image Caching
This is an important one, and MSDN is currently fairly silent about it. If you were ever wondering why your image memory didn't get released after clearing the Source and removing the Image from the tree, you were most likely seeing Image caching in action. This is an intended performance optimization, to avoid (down)loading and decoding the same image over and over again. Instead we keep a cache in memory that we can easily and quickly reuse. This is not to confuse with the browser cache for downloaded files.
While this is a nice and free performance optimization, at times it can blow your memory unnecessarily, especially when you cycle through many images that you will never come back to. Their cache will use up memory for the lifetime of your app. The good news is that you can delete the cache when you decided that you no longer need it:
BitmapImage bitmapImage = image.Source as BitmapImage;
bitmapImage.UriSource = null;
image.Source = null;
Being smart about this can save you quite a bit of memory usage, which is a precious resource on a phone device. In the sample app, go to the "Caching" page and monitor the memory usage as you show/clear the image. Then check the box and try again. You will see a difference of ~3MB in the example case.
You can get the full article here

Good realtime display perfomance and input processing for .NET desktop application approach

I am tasked to write a .NET application that displays a slide-show with some information (words or images) and when the user sees certain items, s/he must immediately press space and the time of the key press must be recorded. The items will be displayed one after the other, for about 50ms. I need then to evaluate the difference between the timestamp of the keypress and and the one when the slideshow started (so I will know how long it took the user to react on the presented item). Edit: I must also record the time of the occurence of the special item.
I need to reduce any unpredictable lags that may occur as the application is running, so that the input processing is as realistic as possible, as well as to reduce any lags between the slides. Currently I am thinking of 3 approaches:
Write a standard Windows Forms (GDI+) application.
Write a WPF application
Write a DirectX-enabled windows forms application that utilizes the Tom Miller's Render loop concept (it is praised as effective in terms of performance).
Something else that you might suggest
I must clarify that I will not use advanced display techniques, special effects or designed for the purpose 3D environments - just plain text slides in different fonts and colours, or images. Unfortunately I cannot cite my sources, but I have read that Windows Forms and GDI+ cannot provide me with the desired accuracy. So, is WPF going to provide me with a better solution? Do I need to use the render loop, or some other approach. I am not experienced in such type of performance requirements for desktop applications, and all advices will be appreciated greatly.

I personally love WPF, but I would be very wary of using it for this application. It is not going to have the same time precision as GDI+ or DirectX. There are all sorts things you'll have to work with like the DispatchTimer and it just wasn't build for something like this. WPF is a whole set of gigantic abstractions on top of graphics and the farther you get away from the metal, you're introducing potential problems. If you want to put a video projected on top of a 3D sphere inside a combobox then WPF is the way to go, but if you need accuracy/precision on the scale you're talking, WPF is not the answer. I don't know where you read that WPF will provide you with better accuracy, I can practically guarantee that it will not.
DirectX would most likely be the most accurate in ensuring that a picture is only displayed for 50ms at a time. But GDI+ would be a decent alternative solution because it will make it easier to deal with text from a programming perspective.
Another consideration, screen refresh rates. yikes. if you do the math most LCDs have a 5ms response rate which is 10% of your allotted time. That and they only display at 60Hz. If you're displaying 20 pictures per second (50ms per picture) it is only going to be on the screen for 3 refresh cycles.
I hope this helps.

50 msec isn't long. Maybe encode and play the slideshow as a video?

Why does my Winforms program reserve so much virtual memory?

I have a C#/.NET 4.0 application that when I start it up shows two windows with about a dozen controls. When I run my program (Debug or Release doesn't matter), before I even do anything in it, I see in Task Manager/Resource Monitor that my program already has upwards of 450MB of private memory. I realize Task Manager isn't the most reliable way of measuring memory usage, but it is one of the most visible to my users.
When I run the VS2010 .NET Memory Allocation performance analysis, for a full run of my program, it reports about 5MB of RAM actually allocated for managed objects (my program normally uses a few unmanaged objects as well, but they are very small and to simplify this investigation I've disabled them, though to no notable effect). Likewise, if I call EmptyWorkingSet() from psapi.dll after my main form has been shown, my private memory drops to ~3.5 MB.
I've already looked at the questions about memory footprints here and here, but those questions seem to be dealing with programs that show up as a couple dozen Megabytes. My program shows almost 500MB, which looks a lot more worrisome.
I can't imagine all of that is from overhead; why is there such a huge discrepancy between the VS profiler and Task Manager?
Update: Interestingly enough, if I comment out a the part of InitializeComponent() that sets up the ImageLists, the number in Task Manager stays under 10MB. I have two sets of PictureBoxes and ImageLists where the PictureBox displays one of four images depending on which radio button in a radio button group is selected.
These lines of code are the ones that seem to trigger the massive memory increase:
//
// directionImageList
//
this.directionImageList.ImageStream = ((System.Windows.Forms.ImageListStreamer)(resources.GetObject("directionImageList.ImageStream")));
this.directionImageList.TransparentColor = System.Drawing.Color.White;
this.directionImageList.Images.SetKeyName(0, "Dir1.png");
this.directionImageList.Images.SetKeyName(1, "Dir2.png");
this.directionImageList.Images.SetKeyName(2, "Dir3.png");
this.directionImageList.Images.SetKeyName(3, "Dir4.png");
//
// modeImageList
//
this.modeImageList.ImageStream = ((System.Windows.Forms.ImageListStreamer)(resources.GetObject("modeImageList.ImageStream")));
this.modeImageList.TransparentColor = System.Drawing.Color.White;
this.modeImageList.Images.SetKeyName(0, "Mode1.png");
this.modeImageList.Images.SetKeyName(1, "Mode2.png");
this.modeImageList.Images.SetKeyName(2, "Mode3.png");
I am using ImageLists so I can use transparency. The Mode images are 100x100 and take up <26KB of disk space each. The Direction images are 208x277 by default and about 75KB on disk. I know png is a compressed format, but even uncompressed in memory I wouldn't expect hundreds of megabytes for these seven pictures.
Is there some inefficiency I'm aware of, and is there an alternate way to dynamically display pictures with transparency?
Conclusion: Something is fishy with the ImageList class. Sometimes it'll lose the alpha channel, and it was causing my program to reserve way more memory than it needed. It also was slowing down the time to draw the main form initially (both while running and in the designer).
Dumping the two ImageLists brought my program down to a much healthier 10MB of RAM. Thanks for all of the suggestions everyone!

My own experience with this problem is that i had 24bit images in my imageList while i had 32bit option set in imagelist's settings.
I've set 24bit in imagelist's properties and the problem has gone. That seems to be a bug which someone should post to MS =)
Sorry for my English.

the .Net framework was designed to run as fast as possible given the resources available. The application will continue to consume more and more memory as it in requested (and is readily available) only letting go when you specifically call the garbage collector or when another application needs the resources it is hogging.
Minimize the app and you should see a better representation of how much memory your application is using.
if you then go back to using it, it will remain at the lower resource state until it gets used and consumes again. minimize it again to see how much is actually (not) being used again. this is built into the .net frameworks memory management system.

Someone explained few reasons where memory jumped from 34 MB to 145 MB: Finding the true memory footprint of a Windows application

png's have transparency already. Just make the white a transparent color and save the image. Then use them normally.

First up, have you tried Debug Diag? It will analyse a dump of your process and give some nifty graphs memory which might help you figure out who has allocated all that memory.
Also, check to make sure that neither your compiled .exe or any of your referneced / loaded assemblies is very large - it is entirely possible that all ~500MB is just loaded dlls. This might happen if (for example) large resources have been embedded into the assembly.