Question Change m_AllocatorLabel after NativeArray is initialized

Hello

I am using this Unity Jobs example to explain the behaviour:

When initiating a native array of Color32 so that I can set the Allocator, the texture colors do not update:

Code (CSharp):

1. var data = new NativeArray<Color32>(m_Texture.GetPixelData<Color32>(0), Allocator.Persistent);

m_AllocatorLabel is set:


Texture Colors do not update:


However when the nativearray is initialized like this, the texture updates correctly:

Code (CSharp):

1. var data = m_Texture.GetPixelData<Color32>(0);

NativeArray Allocator is None because I could not set it when initialized this way:


Texture colors update correctly:


Can someone shed some light please:
- is this behaviour a bug?
- if I initialize the nativearray so that texture colors do work correctly (var data = m_Texture.GetPixelData<Color32>(0) how can I set the Allocator after initialized? I don't see this in the documentation.
- Does Allocator.None behave like Persistent? If I don't dispose off the native array when initialized without setting the Allocator, I can't see an error on the editor logs saying a nativearray was not disposed.

I'm using Burst, sorry if this is not the right place to post as I'm not using entities but i'm using mono and jobs. I'm on Unity 2020.3.22, Burst 1.4.1, Collection 0.15.0 prev .21, Entities 0.17.0-prev.42, Jobs 0.8.0prev.23

 

It's not a bug.

In the first case you create a copy of the texture data. Modifying it has no effect on the actual texture.
In the second case you use the actual texture memory. It's memory is managed by Unity and there is no need to dispose it.

From the documentation:

 

Thank you @julian-moschuering , that explains !

I have another follow up question , maybe I can save opening a new thread please - I am looking to keep the managedarray alive for the life of the game: are there any obvious performance considerations for a NativeArray managed by Unity (disposed by GC I am guessing) and that I use for jobs than a NativeArray I create for a job which I am responsible for disposing off?

 

I don't think there are performance issues but it might not be save to do so as there might be events the memory is reallocated. To be safe you should stick to the documentation and not do that:

Eg refetch the NativeArray each frame and pass it to your job and drop it when calling Apply
or
create your own persisent NativeArray and write it to the texture using SetPixelData. Depending on the Graphics API in use the latter might have a small overhead due to doing an additional copy.