Open StefanOltmann opened 3 months ago
@eymar
Thank you for a hint. I missed the change somehow. Sorry about that.
Can you explain „ // skia makes an internal copy of the nsData bytes“? Does SKIA the same with a Kotlin ByteArray?
Yes it does. Skiko calls this Skia code in the end:
SKIKO_EXPORT KNativePointer org_jetbrains_skia_Image__1nMakeFromEncoded
(KByte* encodedArray, KInt encodedLen) {
sk_sp<SkData> encodedData = SkData::MakeWithCopy(encodedArray, encodedLen);
sk_sp<SkImage> image = SkImages::DeferredFromEncodedData(encodedData);
return reinterpret_cast<KNativePointer>(image.release());
}
But it's happening due to the fact, that Skia needs the control over the lifetime of the memory, which it will use later to rasterise the encoded image into bitmap. We could potentially seek for opportunity to share the ownership of NSData with Skia here, but it requires further investigation and isn't so trivial as aforementioned PR.
If we find a way to make NSData* outlive the decoding of SKImage, we can ditch another copy here. I'll make a ticker for that.
Okay, so this PR fixes that I don't require to have the same bytes three times in memory as I have when I load it as NSData (first), convert it to Kotlin ByteArray (second) and give it to SKIA which makes a third copy.
Two copies in memory is better than three.
Even better would be just one copy. :)
I'll make a ticker for that.
Can you give me a link to that? Then we can close this issue.
Right now we need to convert Apple
NSData
to a KotlinByteArray
, before we can load anImage
from it. This memory copy doubles the memory required and turns out to be a problem for photo manager apps like Ashampoo Photos that do this for thousands of photos.I need a way in Compose for iOS for directly decode an image from the raw bytes of NSData. This should be memory efficient and not copy to a
ByteArray
internally.