I have the following code as part of a game:
protected override void Draw(GameTime gameTime)
{
GraphicsDevice.Clear(Color.Black);
spriteBatch.Begin();
terrainSprite.Draw(spriteBatch);
if (resourceMap.pixels.IsDisposed == false)
{
resources.Draw(spriteBatch, spriteFont);
}
spriteBatch.End();
base.Draw(gameTime);
//Disposes the texture here:
resources.pixels.Dispose();
}
//In the resources class
public void Update()
{
//gD = graphics device
pixels = new Texture2D(gD, 800, 353);
//big update method
//manipulate the pixels texture
}
When I open task manager and look at the resource monitor, the memory usage for 'myGame.exe' is constantly going up by about 8 KB (I realize this is small, but my game holds a LOT of data, so saving every bit I can is important, and it builds up fairly quickly). This is after all other code is commented out except for what is shown here. Then, when I comment out the code: "pixels = new Texture2D(gD, 800, 353);", the memory usage stays constant. I also tried GC.Collect(), but no dice.
Is there anything else I can do to try and stop it? (Sorry, getting rid of the code is not an option :p, renewing the texture is much faster than any other method I've come across to make the texture go blank)
Depending on your Game configuration and really, many other factors, such as how slow everything is running, etc., Update and Draw are not perfectly synchronous with each other and are not guaranteed to be run in the following fashion:
Update
Draw
Update
Draw
Update
Draw
Update
Draw
....
Therefore, since you're Disposeing in one and creating a brand new one in the other, something like this can definitely happen:
Update: create new
Update: create new //PREVIOUS ONE LEAKED!
Draw: disposes only current
Update: create new
Update: create new //AGAIN LEAK
Draw: disposes only current
...
Thus, do not Dispose separately in this fashion; Dispose one time for each new one created, no matter what.
I should also add on that textures, along with some other XNA classes (sound and music, and Effects, to name a few) are unmanaged resources, meaning the GC does not see them at all. You must call Dispose on these.
As Andrew points out in his comment, the best way to avoid these pitfalls is not to recreate textures so often - simply reuse the same one and modify it as you see fit.
It appears that Texture2D are not fully handled by the garbage collector.
So when you stop using it (when reusing a variable referencing it, like here, or during the OnDestroy callback), you have to manually destroy the texture. Here :
if(pixels != null) {
Destroy(pixels);
}
pixels = new Texture2D(gD, 800, 353);
Related
There appears to be a memory leak with WriteableBitmaps when writing to the backbuffer directly and using the AddDirtyRect function multiple times within a single Lock/Unlock. The rectangles need to define different regions within the bitmap. The memory will then leak when you try to discard the WriteableBitmap.
You can recreate it by inserting the following code into a new WPF application. When the application starts, resize the window to create new WriteableBitmaps and watch the memory rise.
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
Image m = new Image();
m.Stretch = Stretch.Fill;
this.Content = m;
this.SizeChanged += OnSizeChanged;
}
private void OnSizeChanged(object sender, SizeChangedEventArgs args)
{
WriteableBitmap bm = new WriteableBitmap((int)args.NewSize.Width, (int)args.NewSize.Height, 96, 96, PixelFormats.Bgra32, null);
bm.Lock();
bm.AddDirtyRect(new Int32Rect(1, 1, 1, 1));
bm.AddDirtyRect(new Int32Rect(2, 2, 1, 1));
bm.Unlock();
((Image)this.Content).Source = bm;
}
}
We need to be able to discard the bitmap so keeping the same one around and reusing it is not an option. We could also not write to the backbuffer directly and instead use WritableBitmap.WritePixels() but it's slower and speed is an issue.
UPDATE:
I've tested the WritePixels method and it leaks all the same. It may be an issue of calling too many writes too quickly in different regions.
We've contacted Microsoft on this issue and it appears to be a problem with the underlying c++ library backing WPF. We haven't been given an promise of when (or if) a fix will come but it is still a bug as of .NET 4.5.1.
There are currently only two ways we have found to work around this problem and they are mutually exclusive. You can either:
Never dirty any subregion of the bitmap, only dirty the full bitmap
The problem with this method is performance. You can try to counteract this by making your bitmaps smaller but there likely many situations where this isn't possible.
Never discard your bitmap
If you're going to dirty multiple subsections of the bitmap then you must ensure it will never be garbage collected unless you're about to close the application. This comes with it's own host of problems as you have to make sure the bitmap is large enough the first time you create it. If users are allowed to resize the window then you'll have to make it fit the entire desktop, but even this is problematic as users can change their desktop resolution or add/remove monitors meaning you'll either have to leak memory or not have enough bitmap to cover the entire possible size of the window.
Hopefully Microsoft will release a fix for this in the future but for the mean time be very careful with WriteableBitmap as it's very prone to leaking memory.
I'm working on a 2D fighting game with XNA (C#). Everything was going well in my game until I added a story mode. There are more than 60 frames. I have a variable whose value changes each time the person presses the spacebar.
I wanted to experiment game state transitions and dispose() (or .Unload()) content when a screen was no longer needed. I have searched about Dispose() and Unload () to save memory that take my textures, but I can not give a value to my variable Texture2D after having called Dispose() for it. (texture.IsDisposed = true).
I have created a ContentManager xContent in a Manager Class.
Texture2D texture;
int image = 0;
____________________
if (Keyboard.GetState().IsKeyDown(Keys.Space))
{
if (image == 0)
{
texture = Manager.xContent.Load<Texture2D>("texture1");
}
else if (image == 1)
{
texture.Dispose();
texture = Manager.xContent.Load<Texture2D>("texture2");
}
}
Draw :
spriteBatch.Begin();
...
spriteBatch.End();
I received an error on spriteBatch.End() of the above paste because I have reloaded the texture. What should I do?
You should not be calling 'Dispose()' on any of the content which was loaded by the XNA content manager. The content manager will manage the lifespan of the content (that's it's job, after all). It ought to make reasonable decisions about when to load/unload specific textures based on usage.
When the content manager itself is disposed then it will dispose all of the content that it's currently managing, so you don't need to dispose individual pieces of content.
Try to to organize it inside your manager. Loading the appropriate texture to the collection as needed and use them and remove if they become do not really need. If the texture will not link it sooner or later pick up the garbage collector.
I am going to have lots of (same looking) zombies in my game.
Is it a good idea to make the texture static, so that SpriteBatch wont need to load a new texture?
I go through the whole zombie list and draw every zombie with the same call, just changing the position. Will SpriteBatch get it? That its exactly the same texture every time? Where could be the disadvantage?
I don't think that the use of static will give you some kind of benefit.
What's sure is that, if you load your Texture2D only once, you save memory and you can draw it how many times you need using the same variable.
Anyway, if you're using only one texture you don't have any problem, because:
Each instance of ContentManager will only load any given resource
once. The second time you ask for a resource, it will return the same
instance that it returned last time.
ContentManager maintains a list of all the content it has loaded
internally. This list prevents the garbage collector from cleaning up
those resources.
Reference here.
I am currently writing a small app which shows the preview from the phone camera using a SharpDX sprite batch. For those who have an nokia developer account, the code is mainly from this article.
Problem
Occasionally, it seems like previous frames are drawn to the screeb (the "video" jumps back and forth), for the fracture of a second, which looks like oscillation/flicker.
I thought of a threading problem (since the PreviewFrameAvailable event handler is called by a different thread than the method which is responsible for rendering), but inserting a lock statement into both methods makes the code too slow (the frame rate drops below 15 frames/sec).
Does anyone have an idea how to resolve this issue or how to accoplish thread synchronization in this case without loosing too much performance?
Code
First, all resources are created, whereas device is a valid instance of GraphicsDevice:
spriteBatch = new SpriteBatch(device);
photoDevice = await PhotoCaptureDevice.OpenAsync(CameraSensorLocation.Back, captureSize);
photoDevice.FocusRegion = null;
width = (int)photoDevice.PreviewResolution.Width;
height = (int)photoDevice.PreviewResolution.Height;
previewData = new int[width * height];
cameraTexture = Texture2D.New(device, width, height, PixelFormat.B8G8R8A8.UNorm);
photoDevice.PreviewFrameAvailable += photoDevice_PreviewFrameAvailable;
Then, whenever the preview frame changes, I set the data to the texture:
void photoDevice_PreviewFrameAvailable(ICameraCaptureDevice sender, object args)
{
sender.GetPreviewBufferArgb(previewData);
cameraTexture.SetData(previewData);
}
Finally, the Texture is drawn using a SpriteBatch whereas the parameters backBufferCenter, textureCenter, textureScaling and Math.Pi / 2 are used to center and adjust the texture in landscape orientation:
spriteBatch.Begin();
spriteBatch.Draw(cameraTexture, backBufferCenter, null, Color.White, (float)Math.PI / 2, textureCenter, textureScaling, SpriteEffects.None, 1.0f);
spriteBatch.End();
The render method is called by the SharpDX game class, which basically uses the IDrawingSurfaceBackgroundContentProvider interface, which is called by the DrawingSurfaceBackgroundGrid component of the Windows Phone 8 runtime.
Solution
Additional to Olydis solution (see below), I also had to set Game.IsFixedTimeStep to false, due to a SharpDX bug (see this issue on GitHub for details).
Furthermore, it is not safe to call sender.GetPreviewBufferArgb(previewData) inside the handler for PreviewFrameAvailable, due to cross thread access. See the corresponding thread in the windows phone developer community.
My Guess
As you guessed, I'm also pretty sure this may be due to threading. I suspect that, for example, the relatively lengthy SetData call may be intercepted by the Draw call, leading to unexpected output.
Solution
The following solution does not use synchronization, but instead moves "critical" parts (access to textures) to the same context.
Also, let's allocate two int[] instead of one, which we will use in an alternating fashion.
Code Fragments
void photoDevice_PreviewFrameAvailable(ICameraCaptureDevice sender, object args)
{
sender.GetPreviewBufferArgb(previewData2);
// swap buffers
var previewDataTemp = previewData1;
previewData1 = previewData2;
previewData2 = previewDataTemp;
}
Then add this to your Draw call (or equal context):
cameraTexture.SetData(previewData1);
Conclusion
This should practically prevent your problem since only "fully updated" textures are drawn and there is no concurrenct access to them. The use of two int[] reduces the risk of having SetData and GetPreviewBufferArgb access the same array concurrently - however, it does not eliminate the risk (but no idea if concurrent access to the int[] can result in weird behaviour in the first place).
Attempting to do SetData() on Texture2D that has been recently Draw()-n by SpriteBatch leads to following exception:
The operation was aborted. You may not modify a resource that has been set on a device, or after it has been used within a tiling bracket.
Can I determine in advance if executing SetData() will throw this exception?
Basically, you have three options:
1) See if SpriteBatch has finished it's operation and call SetData() afterwards. The drawing methods usually are asynchronous. That means that, they just get added to the please-render-me queue and the method returns immediately. What you need is either a callback notification when the drawing has finished or a synchronous call to Draw().
2) Avoiding that SetData() gets interrupted. You can do that by putting it into a critical section which I would not recommend. It should be possible to lock the texture data. It's called LockRect() in Direct3D, it should be similar in XNA.
3) There should be some method like Flush() somewhere that waits until all graphics-related operation have finished.
Sorry for the rather vague help, but you should be able to find the method names from the XNA doc.
Basically no.
The easiest thing to do is to only call SetData in your Update method.
It's bad practice to use SetData within your Draw method, as the device could be doing all kinds of voodoo magic with the old data. This is explained in detail in the "Caution" box on its MSDN page.
Now, up until XNA 3.1 you could use SetDataOptions with Texture2D.SetData. But it looks like that functionality has been removed in XNA 4.0 for textures.
Shawn Hargreaves explains here how SetDataOptions could be used tell the GPU "actually yes I do want to overwrite that data you might be using, don't complain". And why it's difficult to get right.
I've solved a problem like this by creating two textures, and switching between the active one, essentially double-buffering:
void CreateTextures()
{
depth_1 = new Texture2D(this.GraphicsDevice, width, height, false, SurfaceFormat.Single);
depth_2 = new Texture2D(this.GraphicsDevice, width, height, false, SurfaceFormat.Single);
depth_current = depth_1;
...
}
void Draw(GameTime gt)
{
depth_current = depth_current == depth_1 ? depth_2 : depth_1;
Depth.SetData(this.DepthBuffer);
...
}
In my case it wasn't possible to move the SetData outside of Draw, but I suppose that's the nicest way to do it.