Open ddutchie opened 5 years ago
Original PNGCS is written with this in mind actually. But I've never had the need to expose this feature to Unity. Take a look at ImageLine.cs - images in PNGCS are both being read and written line by line already. So it makes sense to expose instance of this line object to Unity as an buffer for step-by-step reading/writing
In 93832f6 you can find WriteLargeAsync. By default it will split allocations into (texture.height) number of parts so GC can release unused ones. It's overload exposes an delegate action to your very custom ImageLine-filling method - letting you implement something more suitable for your particular use case. Let me know if that helps or not
So far in my experience memory usage is a trade-off between it and main-thread CPU time. You probably can't avoid it until Texture2D can be accessed from worker threads. For example, reading texture pixel-by-pixel, while not allocating any heap memory (great), would totally stall Unity main thread (not great).
Nice, thanks for the prompt response. Will test it sometime soon.
There seems so be quite a lot of garbage being created when using these calls.
My use case. I export 7 Large PNG's in succession or in parallel with async. When I run the same process again the Mobile Version crashes due to memory issues.
This suggests that something is not properly discarded. Will run through code and see if I have any suggestions.