Memory management docs/issue/question

[jbruchanov]

Is there any document for memory management/objects lifecycle ?

I'm trying to understand what's necessary to avoid memleaks when using compose multiplatform (specially on iOS side as it's not my primary platform I'm working with, so way to less experienced with any tooling/analysis etc)..

I'm having strange issue, when I'm trying to crop an image which ends up with EXC_BAD_ACCESS crash when calling readPixels(). Following code works, but repeatedly calling it on the previous result like 10+times is always crashing... wondering if I'm hitting basically memory limits (even if calling close()) or I'm just doing something stupid

what's the correct way to handle memory allocation for code like this ?

val targetWidth = (image.width - (step * 2))
val targetHeight = (image.height - (step * 2))
val bytesPerPixel = imageInfo.colorInfo.bytesPerPixel
println("Crop, tw:$targetWidth, th:${targetHeight}, step:$step, bytesPerPixel:$bytesPerPixel")

val rowBytes = targetWidth * bytesPerPixel
val necessaryMemory = targetHeight * rowBytes
val data = Data.makeUninitialized(necessaryMemory)
require(data.size > 0) { "Invalid data size" }
val output = Pixmap.make(
    info = ImageInfo(
        colorInfo = imageInfo.colorInfo,
        width = targetWidth,
        height = targetHeight
    ),
    buffer = data,
    rowBytes = rowBytes
)
return if (readPixels(dst = output, srcX = step, srcY = step, cache = false)) {
    Image.makeFromPixmap(output).also {      
        output.close()
    }
} else {
    throw IllegalStateException("Unable to crop it, readPixels() returned false")
}

Is it necessary to call close on Image/Data/Pixmap instances or it's just good practice to release resources ASAP, or the KMP garbage collector is capable of handling that ?

calling output.close() doesn't have any sideeffect and the result is visible, calling pixmap.close() ends with black image, so I guess that's not wanted... similarly later I'm calling image.close() right after calling the crop...

checked couple github projects and they usually just call Image.makeFromEncoded() and they don't necessary seem to be bothered too much with calling close, but I just doubt that's just simple&easy if this is sort of a bridge to c++ world, there is nothing easy/automatic in terms of memory.

reproducer here https://github.com/jbruchanov/KMPMultiProject/tree/skia_readPixels_issue/AppProject

[jbruchanov]

I'm trying to do some profiling and what is even more confusing, it looks like the crash is actually happening because something is being releases from memory...

Each step is a "CROP" call, if I let the app alone for few seconds, GC releases memory (even if I'm keeping strong reference to Image instance itself)... When I click on a crop again right after the GC, then it's crashing...

I have removed all close() calls and even keeping strong Image references and it's still crashing with EXC_BAD_ACCESS which sort of make sense at this point, but what am I doing wrong in my code that the image data is being unwantedly released from memory ?

[jbruchanov]

I guess I finally figured it out... Keeping reference to Pixmap is fixing the issue.

So looking more into the code and makeFromPixmap is calling RasterFromPixmap

Pixels must remain valid and unchanged until rasterReleaseProc is called. rasterReleaseProc is passed releaseContext when [SkImage](https://api.skia.org/classSkImage.html) is deleted or no longer refers to pixmap pixels.

Assuming if if was calling RasterFromPixmapCopy I wouldn't need to hold explicitly the reference to it. I know skiko is not probably meant to be used directly, but I think a naming consistency or at least basic kdocs would be very helpful...

makeFromPixmap -> RasterFromPixmap makeFromEncoded(bytes: ByteArray) -> SkData::MakeWithCopy -> SkImages::DeferredFromEncodedData

it's hard to assume just based on naming what is actually making a data copy and what is just using pointers and if these names don't match a dev has to always take a look what's actually skiko doing on top of skia.

Feel free to close it or change it to some "we need some documentation" ticket...

[okushnikov]

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.