Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a way to load an Image directly from NSData #887

Open
StefanOltmann opened this issue Mar 11, 2024 · 5 comments
Open

Provide a way to load an Image directly from NSData #887

StefanOltmann opened this issue Mar 11, 2024 · 5 comments

Comments

@StefanOltmann
Copy link

Right now we need to convert Apple NSData to a Kotlin ByteArray, before we can load an Image 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.

@eymar
Copy link
Collaborator

eymar commented Mar 11, 2024

Hi @StefanOltmann ! please have a look at this PR https://github.com/JetBrains/skiko/pull/873/files
This change should be already available in these versions:
v0.7.97 v0.7.96 v0.7.95.1 v0.7.95 v0.7.94

@StefanOltmann
Copy link
Author

@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?

@elijah-semyonov
Copy link
Contributor

elijah-semyonov commented Mar 11, 2024

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.

Screenshot 2024-03-11 at 16 47 27

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.

@StefanOltmann
Copy link
Author

StefanOltmann commented Mar 11, 2024

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. :)

@StefanOltmann
Copy link
Author

I'll make a ticker for that.

Can you give me a link to that? Then we can close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants