I take it that the re-calculation you mention is the text re-flow calculation, as you keep the font size same, but change the page area ?

1. You need to optimize the page rendering/rasterization logic for speed.
2. Adjacent pages can be kept in a lower quality/resolution.
3. Each page can have its own rendering subroutine/task, on a separate worker thread (with a priority queue and cancellation support) that can run separate from page switching.
4. Page switching or resizing simply re-distributes content (start/end) between in memory pages. Actual rendering work is submitted to #3.

Overall effect will be that user can switch or resize as fast he likes to, the content will appear with slight delay, as fast as it can be rendered.

I take it that the re-calculation you mention is the text re-flow calculation, as you keep the font size same, but change the page area ?

1. You need to optimize the page rendering/rasterization logic for speed.
2. Adjacent pages can be kept in a lower quality/resolution.
3. Each page can have its own rendering subroutine/task, on a separate worker thread (with a FIFO queue and cancellation support) that can run separate from page switching.
4. Page switching or resizing simply re-distributes content (start/end) between in memory pages. Actual rendering work is submitted to worker queue (#3).
5. Pages that go out of scope, cancel any unfinished render task in queue.
6. Worker thread picks tasks most recently submitted to the FIFO queue. That is: the page just presented to user is rendered first.

Overall effect will be that user can switch or resize as fast he likes to, the content will appear with slight delay, as soon as its render task in worker queue (#3) is done.

I take it that the re-calculation you mention is the text re-flow calculation, as you keep the font size same, but change the page area ?

1. You need to optimize the page rendering/rasterization logic for speed.
2. Adjacent pages can be kept in a lower quality/resolution.
3. Each page can have its own rendering subroutine/task, on a separate worker thread (with a priority queue and cancellation support) that can run separate from page switching.
4. Page switching or resizing simply re-distributes content (start/end) between in memory pages. Actual rendering work is submitted to #3.

I take it that the re-calculation you mention is the text re-flow calculation, as you keep the font size same, but change the page area ?

1. You need to optimize the page rendering/rasterization logic for speed.
2. Adjacent pages can be kept in a lower quality/resolution.
3. Each page can have its own rendering subroutine/task, on a separate worker thread (with a priority queue and cancellation support) that can run separate from page switching.
4. Page switching or resizing simply re-distributes content (start/end) between in memory pages. Actual rendering work is submitted to #3.

Overall effect will be that user can switch or resize as fast he likes to, the content will appear with slight delay, as fast as it can be rendered.