Reflowable EPUB Pool creation + scroll on update

[JayPanoz]

At the moment the FramePoolManager for reflowable EPUB is using the same strategy for both paginated and scroll when it comes to pushing resources in disposal and creation arrays:

this.positions.forEach((l, j) => {
  if(j > (i + UPPER_BOUNDARY) || j < (i - UPPER_BOUNDARY)) {
    if(!disposal.includes(l.href)) disposal.push(l.href);
  }
  if(j < (i + LOWER_BOUNDARY) && j > (i - LOWER_BOUNDARY)) {
    if(!creation.includes(l.href)) creation.push(l.href);
  }
});

i being the current position index in the positions list, and j the one in the loop.

This means that it will effectively push the next resource in the readingOrder when at the end of the current one, and the previous resource at the beginning.

Since we are using scroll affordances in Thorium Web/Readium Playground, it means the start and bottom of the document can actually have links to both the previous and next resource, with only a single one being ready to be shown in the pool.

While that does not necessarily create noticeable performance issues at the moment, maybe we should update this strategy so that each layout can be as optimised as possible, although it can be a tricky one, see preloading on hover, etc.

[chocolatkey]

@JayPanoz Have you thought about using and observer to determine when the buttons and the start and the end come into view, and using that to trigger the preloading?
Preloading on hover is not a bad idea, but will not help on mobile where the impact is most likely to be noticed.

[JayPanoz]

Ah yeah sorry if that was unclear, it was more of an example to illustrate the hypothetical complexity of the strategy, using a well-known and popular pattern with its pros and cons – had this in Mind since there is a new Speculation Rules API designed to address such performance challenges.

The thing is we know these affordances will be injected through the Injection API so it's problematic to have something hardcoded into the Frame pool Manager IMO. Maybe it could be an option you can set when instantiating the Navigator, or maybe you could even pass your own strategy to override the one built-in. I haven't put a lot of thought into this yet so I'm not sure what would be best.