Web reader doesn't full load images until they are shown despite preloading

[JerwuQu]

Steps to reproduce

This is most noticeable in Firefox, especially with high resolution images (or spreads).
A spread where the issue was very prominent had the resolution of 3620x2560 for example.
To reproduce, open the reader and switch to a high resolution image.
After the image has been shown once, it will remain cached in the browser and you need to either Ctrl+F5 or fully close the browser to be able to reproduce the issue for that image again.

Expected behavior

Displays the image instantly.

Actual behavior

What happens in Firefox is that images are shown as complete black until they have been rendered.
In Chromium, it seems to instead "freeze" the browser page until the image has rendered, resulting in some delay but an overall better experience.
With the example spread mentioned above, it would result in a black image for ~0.5s in Firefox, and a delay of ~0.5s in Chromium.

This caused me to first believe that Komga didn't have preloading at all. On inspection though, I can see that the image has been loaded through a network request, but when switching to said image (same page numbers), I still see the loading lag.

Logs

No response

Komga version

v1.8.3-master

Operating system

Debian 12

Installation method

Docker

Other details

Looking at the code and network inspector, it caches the image properly with :eager="eagerLoad(i)", but because the item still has display:none; it doesn't actually get loaded for rendering.

As an example, applying the following userstyle which overrides the display:none; style, while completely breaking the reader, also fixes the preloading issue for the first few images before breaking.

div.v-window-item {
    display: block !important;
}

One person on StackOverflow claims that using eager for the v-carousel is not enough and that it might also require having a v-img with eager.

While I don't have a Komga development setup right now, I would be willing to help solve this issue.

Acknowledgements

• I have searched the existing issues (open AND closed) and this is a new ticket, NOT a duplicate or related to another open issue.
• I have written a short but informative title.
• I have checked the FAQ.
• I have updated the app to the latest version.
• I will fill out all of the requested information in this form.

[gotson]

I don't quite understand what the symptom is, can you share a video that shows what's the problem?

[JerwuQu]

Sure! Here's an example: https://www.youtube.com/watch?v=CXAa-pcYABk
Notice that when going to the next page, it goes completely black before showing the page, and how it is instant when going backwards.

For this example I used very high resolution images (6000x10000) to make it really prominent, but I can see it with normal manga too.

[gotson]

And that symptom only happens on Firefox, is that right?

[gotson]

Could you share that test cbz you're using? That would save me some time finding / building one for testing.

[JerwuQu]

The black image can only be seen on Firefox, yes. On Chromium browsers it lags the browser instead.

Here is the cbz: https://drive.google.com/file/d/1HXYs7N0e3lK_V9PYOnvy8DUFOXttoRgm/view?usp=drivesdk

[gotson]

Thanks for the file. I can reproduce on both Chrome and Firefox. Most of the development of Komga was done on Chrome, until a few weeks ago, which explains why this was never spotted. Chrome handles this slightly better than Firefox in my opinion.

We don't use v-img though, so i need to find another way to render the images before showing them.

[gotson]

I've done a few tests on Chrome, Firefox and Safari.

Chrome: seems to have some optimization to not render images that have a size but are not in the viewport. No luck there. It's also quite awful at managing page transitions with high definition images. It's always laggy, even after the images have been rendered.

Firefox: I managed to setup some CSS classes to move the images offscreen with a display: block, which makes them render. It works great without page transitions, however when page transitions are enabled, it causes problem. What i managed to do when there are page transitions is to pre-render the i+2 images, so that the transitions to previous/next are smooth. The downside is that if you open a book on page X, the pages X-1 / X+1 will not have been pre-rendered, but the next ones will.

Safari: the most atrocious browser in this test. It doesn't pre-render (like Chrome), and even after the components have been rendered and you go back to previously read pages, it stalls (like Chrome). I think it's agressively disposing of elements that are not displayed anymore, and need to re-render.

[JerwuQu]

Thanks a lot for your effort in solving this! 🥳

I will give it a try after work.

[gotson]

Thanks a lot for your effort in solving this! 🥳

I will give it a try after work.

Well it hasn't been released yet. Wait for the comment on that ticket once released.

[JerwuQu]

I tested it locally on the master branch and it works great in Firefox

[github-actions]

🎉 This issue has been resolved in 1.8.4 (Release Notes)