Investigate if SKStream can derive System.IO.Stream

[migueldeicaza]

And implement its methods in terms of Stream, instead of introducing new names

[mattleibow]

To do this, I had a look and put together SKManagedStream:

Managed bit: https://github.com/mono/SkiaSharp/blob/master/binding/Binding/SKManagedStream.cs
C Header: https://github.com/mono/SkiaSharp/blob/master/native-builds/src/sk_managedstream.h
C Source: https://github.com/mono/SkiaSharp/blob/master/native-builds/src/sk_managedstream.cpp
C++ Header: https://github.com/mono/SkiaSharp/blob/master/native-builds/src/SkManagedStream.h
C++ Source: https://github.com/mono/SkiaSharp/blob/master/native-builds/src/SkManagedStream.cpp

[migueldeicaza]

I see we were thinking about this from two different viewpoints.

Your viewpoint wraps a C# stream into something that can be surfaced to the Skia world, this is very useful.

My request is to make SKStream subclass Stream so that existing APIs in C# that consume streams can be used with SKStreams. This means that we could use SKStreams everywhere where we expect an instance of Stream. But perhaps there is no much use for it, and perhaps we could just live with a "proxy", like SKStream.AsStream() that returns a Stream that can be used to access the underlying stream if needed.

Flagging this as low-priority, until we have better use case.

[mattleibow]

I am closing this as this will involve changing a few base types. Also, I don't think it will be possible as we need to preserve the skia type hierarchy. All is not lost, as there are extension methods and wrappers that can be used with the native streams, without a performance hit.