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

Saving note causes freeze for 10-60 seconds depending on the imported pdf's size. #1189

Open
2 tasks done
atahanacar opened this issue Mar 25, 2024 · 12 comments · May be fixed by #1191
Open
2 tasks done

Saving note causes freeze for 10-60 seconds depending on the imported pdf's size. #1189

atahanacar opened this issue Mar 25, 2024 · 12 comments · May be fixed by #1191
Labels
bug Something isn't working

Comments

@atahanacar
Copy link

atahanacar commented Mar 25, 2024

Before submitting an issue, please check the following

  • I have searched for similar issues (both open and closed) and cannot find a duplicate
  • I agree to follow the Code of Conduct

Describe the bug

When saving a note, the entire app becomes unresponsive until saving is completed.

To reproduce

  1. Open a note
  2. Import pdf
  3. Write/use the note normally
  4. Save/autosave
  5. Experience a complete freeze of the App for 10-60 seconds (proportional to pdf's filesize)

Expected behavior

The app shouldn't freeze.

Saber version

v0.21.2 F-Droid (21020)

Device

  • Device: Samsung Galaxy Tab S6 Lite
  • OS: Android 13 (LineageOS)

Anything else?

v0.21.1 doesn't have this issue.

@atahanacar atahanacar added the bug Something isn't working label Mar 25, 2024
@QubaB
Copy link
Contributor

QubaB commented Mar 25, 2024

What is the size of pdf? Number of pages and size on disk. Can you share it?

@atahanacar
Copy link
Author

atahanacar commented Mar 25, 2024

Happens on any pdf I tried, ranging from 400 KB to 15 MB. Pages range from 15 to 200. Unfortunately, I'm not allowed to share them as they contain sensitive information about other people, but they are all different pdfs from different sources, some from Libreoffice, some from powerpoint etc.

I've also checked the logcat, nothing related there.

Also happens on another device with different chipset: Samsung Galaxy A52

@trashyms
Copy link

Happening with any pdf size.

@atahanacar
Copy link
Author

Just tested it, also happens on Linux flatpak v0.21.2

@QubaB
Copy link
Contributor

QubaB commented Mar 25, 2024

I think that the problem is that during saving note is saved pdf itself. Behavior should be probably changed to not save the pdf itself but only handwriting. This will increase the speed of saving.

It needs to rewrite AssetsCache and Save code. I will try to implement it, but it will be quite a big change.

@atahanacar
Copy link
Author

atahanacar commented Mar 25, 2024

After fiddling around with the flutter profiler, I found out that OrderedAssetCache.add method is the culprit after commit a95f44b. Unfortunately, I have no previous experience with flutter so it's taking some time for me to wrap my head around some things.

@QubaB
Copy link
Contributor

QubaB commented Mar 25, 2024

After fiddling around with the flutter profiler, I found out that OrderedAssetCache.add method is the culprit after commit a95f44b.

You are right @atahanacar. Code inserted in commit a95f44b causes slow saving of note. It should be improved. This part of code (suggested by me) avoided saving notes with missing pdf pages, but causes another problem.

We should switch to different type of comparison of assets - not byte per byte. Thank you for pointing on this commit.

@atahanacar
Copy link
Author

I am working on caching the OrderedAssetCache index of the pdf file in AssetCache using the pdfs file path. This should solve the issue of comparing entire pdf byte by byte for every single page.

@QubaB
Copy link
Contributor

QubaB commented Mar 25, 2024

Comparison of pdf file byte by byte was implemented because code index = _cache.indexOf(value); sometimes returns index -1 (it means that the sequence of bytes is not the same as already cached) even if the sequence was already in cache. And it caused problem with disapearing pdf pages. So I added this additional comparison byte by byte to avoid this problem of function indexOf - but it is slow for large pdf files.

@atahanacar
Copy link
Author

For this reason, I'm adding another check that if a pdf file with the same path is passed to OrderedAssetCache.add twice, it will load the index from a newly added cache that maps pdf's file path to the cache index. I will do a PR soon.

@atahanacar atahanacar linked a pull request Mar 25, 2024 that will close this issue
@trashyms
Copy link

trashyms commented Mar 26, 2024

Could it be done by importing pdf as converted set of images?
Once imported, no pdf capability is used such as find or extract images or text or hyperlink.

@atahanacar
Copy link
Author

No, that wouldn't solve any problems and make others worse. Right now, the linked pull request fixes the issue, so we're waiting for it to be merged. For the time being, you can use the previous version I mentioned above, or compile my commit on your own.

As for the capabilities not being used, that's not actually true. Converting the pdf to images as a storage medium would mean text would be rendered at a single resolution with no way to adapt to zooming in. Also, I'm planning on adding/requesting features that actually make use of the pdf just like you said.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants