Representing a pointer to pixel data as byte[] is disadvantageous

[stakx]

Some methods have a "pointer to pixel data" parameter; for example:

• IWICBitmapFrameEncode.WritePixels
• IWICBitmapSource.CopyPixels
• IWICImagingFactory.CreateBitmapFromMemory

These parameters are currently typed as byte[], which is not an ideal choice, for at least two reasons:

1. Bitmaps can easily occupy a lot of memory. If a bitmap's complete pixel data is represented as a byte[] array, this will cause LOH (Large Object Heap) allocations. These should be avoided if possible.

   One solution would be to represent pointers to pixel data as IntPtr instead, and allocate buffers using Marshal.AllocCoTaskMem. Unmanaged memory blocks are invisible to the garbage collector, therefore there would be no LOH allocation; however some helper methods might be necessary to prevent unmanaged memory leaks.

2. Some WIC methods that deal with pixel data allow passing a pointer and a "stride" value (which allows jumping to the next row in the pixel buffer). Since byte[] arrays cannot be "offset", there is no way to specify any other starting point than the very first pixel in the array (usually the top left).

   Again, the likely solution is to represent the pixel data buffer as IntPtr, and then possibly providing overloads for byte*, and/or byte[], and/or ArraySegment<byte>. Need to check what makes the most sense in practical scenarios.

[stakx]

A nice solution might be to define the actual interface in terms of IntPtr, then provide extension methods on top of that that translate the raw memory pointer to a Span<byte>.