breautek commented on issue #954: URL: https://github.com/apache/cordova-plugin-camera/issues/954#issuecomment-4113373638
thanks for confirming... That rules out the most common source of OOMs. ``` quality: 30, targetWidth: 600, targetHeight: 600, ``` These are likely the cause in your case tbh.. because I know the resize logic is pretty dumb and in order to manipulate the image to shrink the resolution it first needs to load the original image in memory and it does it via a bitmap which is not very conservative to memory consumption, as it basically decodes the image into pixel byte array where each pixel consumes 4 bytes (int32). This worked fine 10 years ago when phones produced small images naturally but a modern device with a 50mp resolution, you can get a picture anywheres between 4000x3000 to 8000x6000 resolution images. Sometimes even higher on flagship device with full resolution settings enabled. While encoded as jpeg or png they may be relatively large, but still tiny compared to raw int32 which would consume between 45mb to 183mb And that data sizes might not sound like much but the per-app memory heaps are still typically limited to 128-256mb in Android, even if the device has several GB of memory available. Android has a [largeHeap](https://developer.android.com/guide/topics/manifest/application-element#largeHeap) -- not 100% sure how much memory that allows the app to allocate in the Dalvik VM but it's typically not a great solution because if the dalvik (java) vm is processing that much memory it tends to get extremely slow. For proof... you can try temporarily omitting the quality and target dimension settings. Also don't use `correctOrientation`. All of these settings makes it load the image as a bitmap to do image manipulation, which is likely the source of the issue. Without these settings, the file should simply get saved to disk without the bitmap load step. I'd expect that you'll fine the OOM issues will stop. Of course, now you have full resolution images instead of smaller images... so if resizing is very important, finding an alternate library to do the resizing will likely be your best solution. If the resizing logic occurs outside of the dalvik VM, as in via native C library then it isn't subjected to that 128mb heap memory restriction since it has raw memory access. It can use as much memory as the device has physically available. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
