[FEATURE] Configure how many pages to preload

[iwa]

Is your feature request related to a problem? Please describe.
from what i've seen, pages are loaded one-by-one, and the loading is triggered by going to the next page
that's kind of annoying when used on mobile with an unstable connection, because sometimes the next page will load quickly, but sometimes it'll takes dozens of the seconds to load the page

Describe the solution you'd like
A setting so we can enable and choose how many pages to prefetch
that way, we could have a "margin" of already loaded pages, and avoid the issue explained above when using a poor internet connection

[aaronleopold]

Hey 👋

Funny enough, this is actually already implemented. The relevant code section is here. If you can confirm a couple of things, we can transition this to a bug and I can look into it sometime this week:

1. Does your network tab show the API calls being made? It should be 3 book page API calls when you first land on the reader
2. Have you ensured you haven't disabled caching in your browser?

Edit for clarity: the pre-fetching itself is implemented, however your suggestion of having a config for controlling how many pages to fetch is not. If the baseline issue you described is in fact a bug, I'll be sure to leave this feature request, instead of converting it to a bug, in order to capture that aspect

[iwa]

I've done some testing:

Specs

• Macbook pro 13" M1
• Arc Browser
• Fiber connection through wifi (theoretical 500mbps up/down)
• Browser cache is enabled
• Connecting to my server through Tailscale

Testing

• Using network throttling in order to really test if network speed impacts the loading time

• When opening a book, it seems to load the first 15 pages

All the URLs follow this pattern:

http://homiwa:10801/api/v1/media/7b45fc79-cc2e-414d-bc43-3b8ff527e380/page/10

• Then, the first 15 pages are correctly cached and only the progress api calls are made

• When crossing the 16th page, it returns to loading page by page

You can see the pages' loading time averaging 5s, the throttling is effective
I've been waiting at least a minute before going to the next page

So i don't think this is working properly, the only way to "cache" images is to open the bottom bar showing all the thumbnails, that will trigger the loading of the pages, but i don't see any 3 pages ahead of prefetch :/

[aaronleopold]

Thank you for capturing all of this - it is incredibly useful, so I appreciate it!

This is definitely a bug then, the loading of 15 pages at once then 1-by-1 afterwards is definitely not the intended functionality. I'll be sure to give you an update once I figure it out and/or push up a fix 👍

[iwa]

you are very welcome! if you need me to make another batch of tests, don't hesitate to ping me

[aaronleopold]

Hello again! I had a very brief debugging session after work today and figured out what was happening. I wanted to give a little outline in case you are curious. The bug is actually a combination of two bugs and a more complicated inefficiency:

1. The first bug that jumped out at me, in particular the (start, 3) part is just wrong
2. The second bug is in the ToolBar component for image-based readers. It doesn't present realistically unless you start reading from a page past the first one. Essentially, the row of images at the bottom would always start at the first page, even if I start reading at the middle of the book. When I open the toolbar in the middle of the book, it would scroll to the middle and load every single page and then plus some after the current 😅
3. The complicated inefficiency is very intertwined with the second bug, but isn't exactly a bug itself. The images on the bottom are virtualized, or in other words they are not all rendered at once. The virtualized count depends on how wide your screen is, in your case it was 15 and in mine during testing it was 23. This means that when the toolbar renders, even if not visible, those pages will be fetched. This, in combination with the first bug, is why I believe you observed a working cache of 15 images and then no more.

I've fixed the first bug and tentatively the second (just want to test that one a bit more locally). I'll want to spend a bit more time thinking through the third issue, but then hopefully the issue is resolved once merged to develop 👍

[aaronleopold]

Hello 👋

This should (hopefully) be resolved in the latest nightly build. Let me know if you face any issues, otherwise I can close this ticket I'll update the request to reflect the configurable aspect 👍

[iwa]

Hey! thanks alot for your hard work
it works fine! only progress api calls are made after images are downloaded

thanks again!

[aaronleopold]

I have implemented this preference option locally. I'll be sure to link the PR once I create one, I'll plan to have it go out with 0.0.2