Repository navigation
feat(preview): preload next and previous image - #3529
Conversation
|
I also added another change in ac80e25 that prevents trying to preload items that cannot be properly preloaded, and c06f239 contains a test for that. Feel free to cherry pick just c06f239, 9cd4b14, and ac80e25 when you don't want the tests. Also, the preloading is currently on the conservative side, only the next and previous images are preloaded. We could also preload the next 2-3 images. @JammingBen Do you have any opinions on that? Making that configurable and turning that into a full blown option for the user or admin settings would probably be a bit too much for this little improvement. |
The media viewer only resolved the url of the file it was showing, so every arrow key press started a new request. Resolve the urls of the files next to the active one as soon as it is displayed, forward first, so browsing a folder feels instant. The loader moves into a composable so the request bookkeeping is testable on its own: one request per media file, joined instead of duplicated, aborted only when the file is neither the active one nor a neighbor. Images that don't take the preview-service path (videos, audio, vault images, svg) are never preloaded, and public link shares additionally get their bytes pulled into the browser cache, with a fresh url resolved once if the signed one turns out to be stale. Along the way a file that recovers from a failed load no longer keeps rendering the error state.
c06f239 to
0cd5968
Compare
I think preloading only the next and previous image is sufficient, let's go with that for now. I'd rather not make it configurable. |
This adds preloading to the image viewer in the web interface.
Description
The media viewer only resolved the URL of the file it was showing, so every arrow key press started a new request. Resolve the URLs of the files next to the active one as soon as it is displayed, forward first, so browsing a folder feels instant.
The loader moves into a composable so the request bookkeeping is testable on its own: one request per media file, joined instead of duplicated, aborted only when the file is neither the active one nor a neighbor. Images that don't take the preview-service path (videos, audio, vault images, SVG) are never preloaded, and public link shares additionally get their bytes pulled into the browser cache, with a fresh URL resolved once if the signed one turns out to be stale.
Screenshots would not be helpful here, but maybe a video?
Related Issue
None yet, but I can open an issue as well
How Has This Been Tested?
There were two layers of testing:
packages/web-app-preview/tests/unit/composables/useMediaFileLoader.spec.tsTo test it, build it and run it and open a folder with a lot of images (for example JPG) in the browser. Then scroll through them using the cursor keys and you will see that the next and previous image load almost instantly now.
The results could be more significant when testing it against a remote server. When it's tested against a server running on local host, the preloading will not be that visible.
Types of changes