È sicuramente una buona idea separare il layout delle pagine dal rendering. Metterli su fili diversi è una buona idea. Non penso però che la soluzione sia di fare un layout speculativo a diverse dimensioni. Penso che finirai per fare un sacco di lavoro inutile. Inoltre, non mi piace l'idea di forzare l'utente a un certo numero di dimensioni.

Quello che farò dopo è profilare la tua applicazione per vedere cosa impiega più tempo durante il layout della pagina. Un profiler ti dirà quale funzione occupa più tempo nella tua applicazione. È quindi possibile esaminare quella funzione per determinare il motivo per cui sta impiegando così tanto tempo. Spesso un'operazione può essere eseguita più velocemente utilizzando un layout di dati diverso, una struttura dati diversa o un algoritmo diverso. Ad esempio, la ricerca del valore massimo in un array richiede il controllo di ogni elemento una volta per vedere se quell'elemento è più grande del massimo corrente. Ma se l'array è già ordinato, richiede solo una lettura dell'ultimo elemento.

Una volta che hai profilato il tuo codice, puoi lavorare per rendere quelle funzioni più veloci o pubblicare più domande qui su modi migliori per affrontare il problema.

Considero che il ricalcolo da te menzionato sia il calcolo del flusso del testo, man mano che si mantiene la stessa dimensione del carattere, ma si cambia l'area della pagina?

1. Devi ottimizzare la logica di rendering / rasterizzazione della pagina per la velocità.
2. Le pagine adiacenti possono essere mantenute con una qualità / risoluzione inferiore.
3. Ogni pagina può avere la sua subroutine / attività di rendering, su un thread di lavoro separato (con una coda FIFO e un supporto per la cancellazione) che può essere eseguito separatamente dal cambio di pagina.
4. La pagina che cambia o ridimensiona semplicemente ridistribuisce il contenuto (inizio / fine) tra le pagine di memoria. Il lavoro di rendering effettivo viene inviato alla coda di lavoro (n. 3).
5. Pagine che escono dall'ambito, annulla qualsiasi attività di rendering incompleta in coda.
6. Il thread dei worker preleva le attività più recentemente inviate alla coda FIFO. Cioè: la pagina appena presentata all'utente viene visualizzata per prima.

L'effetto complessivo sarà che l'utente possa passare o ridimensionare quanto più velocemente gli piace, il contenuto verrà visualizzato con un leggero ritardo, non appena l'attività di rendering nella coda di lavoro (n. 3) sarà completata.

Il contenuto di una pagina non dovrebbe cambiare in base alle dimensioni dell'area di visualizzazione. Stai rilevando una complessità inutile perché stai trattando le pagine dei libri come se fossero pagine HTML. Non lo sono.

Pagina 47 di "Treasure Island" dovrebbe essere lo stesso contenuto, indipendentemente dal livello di zoom. La maggior parte dei lettori di e-book onora l'impaginazione del libro stampato originale.

Una volta eliminata la necessità di mescolare i contenuti, il rendering e lo scorrimento delle pagine diventano molto più semplici. Non importa se si utilizza un'opzione di zoom percentuale o un'opzione di dimensioni fisse (piccola, media, grande, ecc.) O si utilizza la dimensione fisica della finestra. Per ciascuna dimensione del display, devi solo decidere il carattere appropriato, adattare il testo in orizzontale e lasciarlo estendere verticalmente con una barra di scorrimento.