Next pages show current page instead of loader when flipping

[mediavrog]

Version: 1.0.0-beta.4
used with VueJS3 inside nuxt

Steps to reproduce:

• create flipbook with >10 images/pages
• flip quickly between pages when network is weak (mobile or developer tools network speed throttling)
• notice that the image on page being flipped appears briefly (as long as it takes to load it) as the next page

<template>
  <div>
    <client-only>
      <flipbook
          class="flipbook"
          :pages="images"
          :pagesHiRes="imagesHq"
          gloss="0.5"
      ></flipbook>
    </client-only>
  </div>
</template>

What I expected:

• during loading, I'd expect a blank page with the loading indicator

Will attach a video

[mediavrog]

23-01-22-19-14-14.1.mp4

[kabaluyot]

@mediavrog that use case looks great. How did to worked with opensea? The image src points to html page with flipbook?

[mediavrog]

@mediavrog that use case looks great. How did to worked with opensea? The image src points to html page with flipbook?

animation_url is used. Html and assets need proper CORS then all works well

[ts1]

I tried it on my demo page and was able to reproduce it on Chrome's slow network emulation, but not on an Android machine on a very slow network with Wi-Fi turned off.

Flipbook-vue loads the same image URL in advance with new Image and then after onload actually uses it in <img>, background-image etc.
This means that if caching is properly enabled on the browser side, this problem will not occur.
Conceivably, the server on which you are hosting the image does not allow caching properly?

[mediavrog]

I set cache to one week and headers look alright.
I wonder if an iframe could somehow interfere with this.

[mediavrog]

Ok I also noticed the issue occurs mainly if I disable caching in the network console. But shouldn't the flipper show the loading svg in that case and then the image?

[ts1]

It should, but since it is difficult to manage strictly, it treats URLs as cached once they have been loaded successfully.

[mediavrog]

I see.
A proper caching inside the plugin would resolve this then..