ContentManager Out of Memory before loading any data - c#

I'm trying to load data in XNA, however, whenever I use the ContentManager it throws an out of memory exception. This occurs when I load my first resource. It's a 32x32 pixel image.
I'm using:
contentManager = (Application.Current as App).Content;
contentManager.Load<Texture2D>("Head");
I've been using this for ages and have no clue why it won't work now. Does anyone have any suggestions to get me past this?

I've experienced this one time, it would occur consistently after coming back from a phone task (in my case it was the IAP interface).
I worked around it by delaying the content load. My assumption was that the IAP task itself was using a lot of memory and I needed to give some time for those resources to free up before trying to allocate any more resources.
You could try adding a delay before doing the content loading (not sure when you are doing it, it should be fine if you are doing it in a place like Game.Initialize though).

Related

Removing a SoundEffectInstance without using 'dispose' in C# XNA

I've run into a slight problem. When I restart my game (by running my own initialize method), I can successfully reload all my objects/variables. But the initial SoundEffectInstance I used continues to play while a new instance is created. This results in multiple instances of the same music being played simultaneously.
What I'm trying to achieve is a way to get rid of the first instance when making a new one.
instance.Dispose(); can't be used as it means I can't re-initialize the sound.
I tried using a list to solve this (removing instances before restarting game), but it seems I can't CreateInstance() from within the list, restricting me from initializing the sound to begin with.
Arrays don't seem to offer a solution either. Any ideas?
First off, you probably shouldn't use SoundEffectInstance for music - this results in the entire song being loaded into RAM uncompressed - which eats up a ton of space relative to streaming an MP3/WMA from disk using Music.
If you want to dispose all content then you should unload the ContentManager that has all of your content. Then you can recreate the content - it will take some time to re-load it from disk but you will have a clean set of content if that's what you're after. Keep in mind that a SoundEffectInstance contains unmanaged resources, so the only way to "remove" it is to dispose it or unload its ContentManager.
If you don't want to do that then you should be preserving references to your content and then you can manually do things like stop:
http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.audio.soundeffectinstance.stop.aspx
You should use mediaplayer.play() to play a song instead of SoundEffectInstance and then
you can just have a if statement that you can say if X happens then mediaplayer.play()
else
mediaplayer.stop(); or
mediaplayer.pause()

Find problems causing overload of program

I have a bot that plays a flash game automatically. I have loaded the flash object through an extended WebView a friend coded for me and I use native imports to send click messages to the handle. Everything works good for about 30 minutes. After that the bot, GUI and whole mechanism starts getting slower and slower, lagging more and more, eventually ending up clicking totally different coordinates. I suspect there's a memory leak or performance issue in my source code. How can I find that out or fix it?

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

Decoding a jpg in the background in WP7

I have a bunch of apps in the marketplace, and so far I have been able, by changing my functionality or going the extra mile, to work around the issue of being unable to decode a jpg in the background into a WriteableBitmap.
I am finding a situation where I can't think of good ways to "work around" the issue. I need to decode the image I get from MediaLibrary, reduce it's resolution to something managable (800x800), rotate it potentially and save to local storage. By far, the thing that takes the most time (80%) is decoding the bitmap to 800x800 - it takes between 700ms to 1000 ms. A user may add 7-10 images when starting, which translates to ~10 seconds of waiting for the images being added.
I tried doing this lazily, but at some point you need to pay the piper and the app essentially stutters for ~1000ms at that point and the experience is not great.
Is there an alternative I am missing for loading the image in the background somehow?
(Note on why CreateOptions.BackgroundCreation is no good for me: It loads the image into a BitmapImage which is great if you want to just use it, but not so great for what I need to do which is create a copy in Isolated Storage).
Unfortunately something within the constructor of BitmapImage needs to run on the UI thread. :(
I haven't found a workaround but also haven't seen it take anything as long to decode as you're stating.

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.

Categories