La plupart des pages PDF se rasterisent en quelques millisecondes, au point qu’on n’y pense même pas. Mais lorsqu’un utilisateur ouvre un plan d’ingénierie géant, une page saturée de tracés vectoriels ou un document rempli de transparences, le rendu peut durer assez longtemps pour bloquer l’interface. Dans ce cas, l’utilisateur a besoin d’une chose très simple : pouvoir annuler le rendu en cours au lieu d’attendre que la page finisse de se dessiner
PDFium prévoit déjà ce besoin avec son API de rendu progressif. Le vrai travail côté Delphi consiste à l’intégrer proprement à la boucle d’interface, à convertir la pause en annulation explicite et à fermer correctement le contexte de rendu quel que soit le point d’arrêt
L’API de rendu progressif que PDFium fournit déjà
À côté de son rendu monolithique, PDFium expose une variante progressive qui découpe le travail en plusieurs tranches. Le moteur peut ainsi commencer, rendre un morceau, demander s’il doit continuer, puis reprendre plus tard jusqu’à la fin
Cette surface est exactement ce qu’il faut pour garder un visualiseur réactif pendant les pages lourdes
Réutiliser la pause comme mécanisme d’annulation
PDFium attend un callback de pause qui lui indique s’il doit temporairement rendre la main. Dans une application interactive, ce point d’extension peut devenir un signal d’annulation : si l’utilisateur passe à une autre page, zoome ou ferme le document, le callback demande l’arrêt au lieu de poursuivre
Garder le jeton vivant pendant toute la boucle
Le contexte de pause ou d’annulation ne doit pas être un objet éphémère. Il doit survivre pendant toute la durée du rendu progressif, sinon le moteur finit par consulter un état déjà libéré ou obsolète. C’est un point de cycle de vie, pas simplement de syntaxe
Fermer le contexte de rendu quelle que soit l’issue
Qu’un rendu se termine normalement, s’interrompe parce qu’il a besoin de continuer plus tard, ou soit annulé par l’utilisateur, le contexte interne doit toujours être fermé proprement. Si ce nettoyage n’est pas garanti, vous finirez par accumuler des ressources pendantes ou par réutiliser des objets dans un état incohérent
Trois issues possibles, et ce que contient le bitmap après annulation
Au niveau fonctionnel, il faut raisonner sur trois résultats : rendu terminé, rendu interrompu pour continuation, rendu annulé. Après annulation, le bitmap cible peut contenir un résultat partiel. L’interface doit donc savoir si elle l’affiche, le vide ou le remplace, selon le contrat choisi
Jeton nul et callback sans branche inutile
Une intégration propre simplifie aussi le chemin nominal. Quand aucun mécanisme d’annulation n’est fourni, le callback peut suivre un chemin simple et sans branchement excessif. Quand un jeton est fourni, il devient la source d’autorité pour arrêter le rendu. Cette séparation limite la complexité et rend le comportement plus prévisible
En pratique, le rendu progressif annulable est moins une fonctionnalité « nice to have » qu’un élément de base d’un visualiseur PDF réactif dès que les documents sortent du cas trivial