[Coil 3] Introduce ByteBufferMetadata about coil HOT 4 CLOSED

Sounds good, I think we can probably add this after #1969 is merged. I'll leave the implementation to you

from coil.

Do you know how much overhead this avoids? I'm not totally opposed to it, but ideally we want to use ImageSource.Metadata sparingly as it couples Fetchers and Decoders.

Originally AssetMetadata, ContentMetadata, and ResourceMetadata were added as the gains were significant since it avoided copying a full video file for VideoFrameDecoder.

from coil.

Do you know how much overhead this avoids? I'm not totally opposed to it, but ideally we want to use ImageSource.Metadata sparingly as it couples Fetchers and Decoders.

Originally AssetMetadata, ContentMetadata, and ResourceMetadata were added as the gains were significant since it avoided copying a full video file for VideoFrameDecoder.

This can totally avoid heap thrashing and OOM if user want to decode a DirectByteBuffer
Actually, we'd better implement a ByteBufferImageSource, not Metadata
Then we also provide a okio Source, but data is lazily copied to okio Buffer(art heap) when user need it

Given that there is a 1GB image file(too extreme), for some reason user cannot get its java File Object, only file descriptor is available
Then we construct its FileStream, get its FileChannel and map to a MappedByteBuffer(or mmap this fd)
given coil's current implementation, we load the ByteBuffer totally to a okio Buffer(art heap)
Art will crash with OOM immediately

from coil.

The most interesting thing is, unlike ByteArray, ByteBuffer may represent a range of virtual address, where its page cache maybe not even populated yet

from coil.