2 images (1920x1080) not loading on Android

Thank you for the answer.
So, it is a memory capacity issue.
The editor and preview crashes when you opened a note with the big images.
I don’t know which model of Android phone you use but I’m afraid that I can’t help you with this issue since it depends on your device.
The main reason is as I answered above.

It is a Pixel 3a with 4GB of RAM. I’m note sure if it’s a RAM issue as I have more that 1GB free.

Image data:

  1. 279,8 kB (1920x1278) JPG (inkdrop://file:fXBfsGYbm)
  2. 392,4 kB (1920x1309) JPG (inkdrop://file:1ao8k_Fu5)

I hope this helps. I could send you the images if you think it’s worth debugging.

It sounds strange that it happens on Pixel 3a which has sufficient RAM.
Okay, I’ll look into it.
I’m currently working on the new version of the mobile app, involving fundamental changes right now.
Once I’ve finished this work, I’ll try to reproduce it on my Android phone!

1 Like

Just to let you know:
I haven’t had the issue for a while now. Perhaps it was something about the file format. Sadly I can’t remember with what application I saved the problematic JPG files.
When it happens again I’ll let you know here.

Thanks.
I have reproduced it several times with my note with some large screenshots on my iPhone XS.
The UI freezes and I can’t open another note.
Inkdrop v5 is about to be released. I’ll work on it after that!

1 Like

A quick update:

I suspect a reason why the app becomes unresponsive is that the app takes too long time to decrypt images as the decryption process is performed in JavaScriptCore which is not performant or memory efficient.
I guess we need it to be performed in native code to avoid this bottleneck.
It’d be a big challenge though, worth trying it.

Memo:

1 Like

Good news!

1 Like

Thank you for the reminder. This indeed looks impressive - I’m super looking forward to the new Android version :pray::smiling_face_with_three_hearts:

1 Like

Successfully integrated it with the app and it works great.
A 4MB PNG image (3000 × 1688) is displayed without hung up on Android and iOS!

But there is one more thing that can improve the performance further: Native caching.
Because passing images in base64 through SQLite -> RN -> WebView is sooooooo slow.
Images need to be cached in fs and loaded directly from WebView.
I’ll try it.

1 Like

Wouldn’t this also increase the data storage by nearly 2x? It’s probably still a good compromise to make, CPU time vs storage.
Perhaps there could be an option for image/attachment caching?

No, it wouldn’t increase the local storage usage.
I’m planning to just store images to local storage as files instead of to SQLite database, so they can be loaded directly from WebView via file URI.

Ah okay thanks for the clarification :+1:

v4.1.0 beta is out!
Can you please test it?

https://forum.inkdrop.app/t/mobile-v4-1-0-beta-testing/2358

Cheers

Hello Takuya,

first congratulations and thank you for looking into the image problem!

At the current state though the images won’t load with an updated version. I guess the images aren’t in the cache yet and Inkdrop does not sync then again.

Hi Marco,

Thank you for testing it!
That’s weird.
I wonder if it failed to write images to the app document directory.
Because the app basically checks if it has an image in the document folder before fetching it from the database.
Can you check if the app gets any errors like permission denied with Logcat on Android Studio?

https://developer.android.com/studio/debug/am-logcat

I’ll check if there is another possible issue.

I’m trying this right now. Can I send the output to you somewhere securely?

I’ve checked the permissions. You are right - they weren’t active. Are those new? Sadly Android has not notified me. Perhaps an additional check to grant them would be great.

After granting manually I got this:

Ah it’s self hosted via couchdb btw :sweat_smile:
Oh you have just trouble with me :grimacing:

Ohhh that makes sense! I didn’t test with a custom couchdb setup.
Actually, I updated the beta app 2 hours before to add some error handlers.
I’ll test it tomorrow.
Can you see the files stored in your CouchDB? They should look like:

{
  "_id": "file:8CwjPJOg3",
  "_rev": "1-af318e0e31b090a6b9af065185daf248",
  "createdAt": 1555320967747,
  "name": "ios-icon_01@76.png",
  "contentType": "image/png",
  "contentLength": 4803,
  "md5digest": "fe7484d752914507459aa46eb517375f",
  "publicIn": [],
  "_attachments": {
    "index": {
      "content_type": "image/png",
      "revpos": 1,
      "digest": "md5-/nSE11KRRQdFmqRutRc3Xw==",
      "length": 4803,
      "stub": true
    }
  }
}