amake
commented
1 month ago Thanks for the report. Ideally this shouldn't happen, but I have not optimized Orgro for this use case.
From the app logs it seems to try to copy each image from external storage to the app's data storage.
This is how file_picker_writable works. On the native layer it copies the file to a location that is guaranteed to be readable from the Flutter layer, then returns the URL to the Flutter layer for the application to handle.
I assume this approach was taken for two reasons:
- To handle "Open With App" scenarios where the data is arriving at an unpredictable time and may not be available again at an arbitrary later moment
- To avoid sending the file contents over the Flutter MethodChannel, which may be more costly than accessing it directly from Flutter
I think it could be feasible to avoid the copy by adding a "no copy" flag to flutter_picker_writable that returns the data directly over the MethodChannel.
Therefore it seems that having too many images displayed at once is the problem
Ultimately you only have so much RAM. The images need to be in RAM. So in the limit this is not really avoidable.
Maybe using
Imageand providing the external storage filepath to it, instead of returning just the raw bytes, would already work
I'm not seeing a code path that doesn't load the entire file. However it does look like I could specify cacheWidth and cacheHeight in Image.memory to reduce the cached data.
fw623
Testing
What I expected to happen
I expect the app to show inline images without crashing (in this case local images from the external storage), even when an org-file contains many such images.
What actually happened
The app shows the spinning progress bars in place of the images for a few minutes and then eventually all or most running services on the phone are killed by the memory manager due to memory pressure (checked in the system log), and eventually Orgro is also closed/killed. From the app logs it seems to try to copy each image from external storage to the app's data storage.
This crash happened for a file containing over 300 images (~3MB each) which are each referenced by relative links (
[[file:../assets/image1.jpg]]or similar) and showing all at once, but iirc also happened with about 100 images in other org-files. The org-file and images are both on external storage with the correct permissions for Orgro.Keeping the sections hidden and opening one after the other, waiting for each image to load before opening the next section, works until about 80 images (~3MB each) are loaded, then the same crash as described above happens.
Workaround
Opening sections one after the other, but this time closing all others before opening the next, works and leads to no crash.
Details
Tested on Orgro 1.37.6, Android 14 (GrapheneOS) on a Pixel 6A.
Cause
Therefore it seems that having too many images displayed at once is the problem. To some extent this is kind of expected because each
LocalImageis loaded by reading all its bytes and those seemingly are kept in memory as long as the image is displayed: https://github.com/amake/orgro/blob/3de1d6a820e28d4119e5a6f7685cea1dcca6ff7d/lib/src/components/image.dart#L76Solution (?)
I have no experience with Flutter, so I don't know if the following ideas would actually work. Maybe using
Imageand providing the external storage filepath to it, instead of returning just the raw bytes, would already work. Or maybe some kind of downsizing and caching of these downsized images would be necessary (which would also improve performance because it doesn't always have to load the full image when changing section visibility). I have also seen that Flutter has anImageCache, maybe that already handles such problems.I don't know for what reason it tries to copy each full image to the app's data storage, maybe that can be avoided as well.