Preparation for infinite scroll, since there will be a wrapper which fits its content in width and height, thus, percentage based dimension won't work anymore
Instead of getting the whole download status, which contains all queued/active downloads, the download status should be read from the cache for only the required chapters
Automatically choose the progress bar position based on the available space.
Previously it was only possible to automatically switch from a horizontal to a vertical position but not the other way around
By the time the scroll area got scrolled to the start of the visible pages, the previous/next page wasn't yet shown and thus, the scrollable area wasn't updated yet.
Thus, in case the scrollable area grew in width due to the page change, the start never got scrolled into view due to triggering the logic too early.
Only really relevant for the "progress bar slot" prop to prevent the slots from unnecessary re-rendering, since depending on the total pages, this can impact the render performance on page changes heavily
The page change handling of the progress bar was inverted while RTL was the set readers reading direction.
However, this is only relevant for the horizontal progress bar
Instead of immediately updating the value once the page count changed, it got updated after "pagesToSpreadState" changed, which was after the rendering finished.
This was the actual root cause of what was tried to be fixed with 9ab6ec89c7
For the double pager the current page text needs more reserved space since two pages are displayed at once which changes the current page text to "<page1>-<page2>" instead of just "<page1>"
I was unable to find a fix for this problem, thus, the only solution I see is disabling this functionality for the continuous readers.
Due to preloading leading pages, the layout got shifted once the pages got loaded.
This messed with the scroll position which caused the top of the scrolled into views pages to not be at the top of the viewport anymore.
In case the "tap zone layout" setting value got changed from or to the same value as the default value, the preview was never shown due to the canvas being reused and therefore not triggering the useEffect
For continuous pagers the chapter transition page is always visible regardless of the current "transitionPageMode".
However, this was not properly checked and thus, it wasn't considered to be visible and instead of opening the previous/next chapter, the transition page got set to be visible first and only with the second hotkey press did the chapter get opened
The min/max limit was only acknowledged when the value was changed via MUIs step logic.
In case the number got inputted via keystrokes the limits did not get applied
Re-rendering the component isn't too expensive and unmounting it improves the re-rendering caused by page changes since it doesn't get updated.
This removes ~7ms on a "current page" state update and ~25ms caused by the chapter update due to the "last read page" change
Since "pagesToSpreadState" isn't part of the dependency array and also would decrease the render performance if it was (see reasoning of c79f7cc874), the array reference might be out of date and thus, the guard might not work correctly
Convert clicks on the progress bar in such a way, that there is a "padding" around the page "dots".
Thus, e.g. even if the click was actually for page 1, if it is inside page 2 padding, it will behave like it was a click for page 2
