Texture2D Memory leak

Hi,

I'm trying to solve a memory leak with Texture2D data.

I'm getting texture data as a data structure. The input data has width, height, and an array of the pixels as byte values (0-255).

Here are the relevant code snippets:

Code (CSharp):

1.    
2.     Texture2D                                 newTexture;
3.     List<Color>                             newColors = new List<Color>();
4.    
5.    
6.     void Start () {
7.        
8.         newTexture = new Texture2D(0,0);
9.     }
10.    
11.     .
12.     .
13.     .
14.     .
15.     // In texture handling method. inputData is the data structure I get
16.     newTexture.Resize(inputData.TextureWidth, inputData.TextureHeight);
17.     newTexture.Apply();
18.    
19.     // Change input color to Unity format
20.     float colorValue;
21.     int imageSize = newTexture.width * newTexture.height;
22.     if(imageSize > 0)
23.     {
24.         // Get flat array, convert it to texture
25.         for(int n = 0; n < imageSize ; n++)
26.         {
27.             colorValue = inputData.TextureImage[n] / 255.0f;
28.             newColors.Add (new Color(colorValue, colorValue, colorValue));
29.         }
30.         newTexture.SetPixels(newColors.ToArray());
31.         newTexture.Apply();
32.         GetComponent<Renderer>().material.mainTexture = newTexture;
33.     }
34.    
35.     newColors.Clear();
36.  

I tried using a new Color[] array for the colors, but it made no difference.

Thanks.

 

Errors?

I'm not sure how you can confirm that this is a memory leak without actually proving it in the first place. What is the expected result, and what is the result you are getting?

I'll be honest and say I doubt there's memory leaking issues, nor does it sound like this is a memory leak issue.

Prove me wrong.

 

Thanks for the reply. I forgot to mention the symptoms.. My bad.

While this is running, memory usage for both Unity Editor and the published exe increases by ~15mb per second. This goes on for a few minutes if I let it run.

I can toggle the texture handling off. When it's off the memory usage stays the same.

Proof?

 

Actually, this does sound interesting.

I was looking in to the core of bitmaps a while ago and there is actually situations where a bitmap can have a serious memory leak. I don't think this is the same though.

One thing I'd suggest is going through the whole Color.FromArgb as opposed to using new Color.

Could you tell me the count of colors that you have at the end of the iteration? Also, i'd recommend using a more robust system rather than adding them all to the list and not thinking of duplicates. Something like a dictionary would work well, I guess.

 

Speed is more important to me than memory. Wouldn't finding duplicates be slower than dumping the whole array? And I do need an array for SetPixels, eventually.

Is Color.FromArgb native Unity? The scripting API does not mention it.

 

You should balance speed and memory usage. Imo having the fastest game in the world but taking up too much RAM for the program to actually run on a standard computer seems fairly unreasonable.

A dictionary takes a unique key, so there's no way that you could add a duplicate. That would fix that.

I apologise for the fromargb. I'm used to using XNA, so forget sometimes.

My point still stands, though. If you're initializing 100,000 colours, do you honestly think that the program is not gonna suffer? I think it's best to see what the Unity devs to get involved in this.

 

Update:
I've minimized the code to a single script. You can download the whole (183k zipped) project here:
https://goo.gl/axFJDs
The problem seems to be when creating a new List each frame. I do use List.Clear() at the end of the code, not to mention the GC not doing its job.
Even when I used one list but changed its size, the memory leaked.

 

Update:

Apparently this is a bug with Texture2D.Apply(). It's so deep, Unity's profiler did not show the leak, but external tools did. Unity have acknowledged the problem and are seeking out a solution. No date was given. Thanks for the help

Nir.