Workers, thread principal et rendu

Sixtyfold dispose d’un seul design de rendu TypeScript avec trois hôtes : un worker OffscreenCanvas, un adaptateur asynchrone sur le thread principal et le point d’entrée du rendu côté serveur. Canvas2D est le seul backend graphique.

La sélection du renderer fait partie de LineChartOptions et StockChartOptions. Le mode résolu est disponible via chart.getRenderMode().

Sélection automatique

renderMode: "auto" privilégie un worker lorsque le navigateur prend en charge Worker, OffscreenCanvas et le transfert de canvas. Il revient au thread principal lorsque ces capacités font défaut ou que la création du worker est bloquée de manière synchrone, notamment par une Content Security Policy restrictive.

const chart = new LineChart(canvas, { renderMode: "auto" });
await chart.initialize();

console.log(chart.getRenderMode()); // "worker" or "main"

renderMode: "worker" exprime une préférence, pas une promesse ; il revient toutefois en arrière lorsque le rendu par worker ne peut pas démarrer. Utilisez getRenderMode() pour la télémétrie et les informations de support.

Mode worker

Le mode worker transfère le contrôle du canvas et des grands buffers typés. Il est la voie recommandée pour des graphiques interactifs de plusieurs millions de points car la construction de la hiérarchie, le culling, le layout et le dessin n’occupent pas la tâche UI du navigateur.

Les callbacks exécutés sur le thread principal, par exemple le rendu de tooltips personnalisés, reçoivent des messages compacts du renderer plutôt qu’un accès direct à l’état du worker. Veillez à ce que les callbacks restent déterministes et rapides.

Mode thread principal

Utilisez renderMode: "main" pour les environnements de test, les navigateurs sans canvases transférables, les hôtes stricts qui interdisent les workers, ou les graphiques statiques plus petits où une intégration plus simple prime sur l’isolation de la tâche UI.

L’adaptateur du thread principal livre délibérément les messages du renderer de manière asynchrone. Ne supposez pas qu’un appel à setData ait synchroniquement achevé sa première image ; utilisez des statistiques ou une interface de disponibilité au niveau de l’application lorsque l’achèvement d’une image est important.

Les vérifications de release testent Line et Stock tant via le chemin du thread principal que via le chemin par défaut de production auto dans Chromium, Firefox et WebKit. Sur les moteurs capables, auto résout vers un worker OffscreenCanvas. Le contrat de worker forcé s’exécute aussi dans Chromium. Cela vérifie la compatibilité, pas une garantie de fréquence d’images indépendante du dispositif.

Dimensionnement et DPR

Définissez la largeur et la hauteur CSS du canvas via la mise en page. Sixtyfold Charts observe les changements de taille de l’élément et de ratio pixel-appareil, puis met à jour le backing store et la mise en page du renderer. resize() reste disponible lorsqu’un hôte modifie la mise en page d’une manière qui ne peut être observée immédiatement.

Évitez de définir uniquement les attributs de backing-store du canvas width et height pour des graphiques responsives. Ces attributs sont des valeurs de backing-store, tandis que les champs publics de tailles et de style de Sixtyfold Charts utilisent des pixels CSS.

Content Security Policy

Une politique de production restrictive nécessite couramment :

default-src 'self';
script-src 'self';
worker-src 'self';
img-src 'self' data: blob:;
connect-src 'self';

Adaptez cet exemple à l’application plutôt que de le copier à l’aveugle. Les images d’overlay distantes exigent que leur origine figure dans img-src et des en‑têtes CORS compatibles.

Visibilité et nettoyage

Le graphique du navigateur met en pause ou évite le travail inutile lorsqu’il n’est pas visible. L’intervalle facultatif de maintien en vie pour Safari est désactivé par défaut et ne devrait être activé qu’après avoir reproduit la libération des ressources sur les versions ciblées de Safari.

Appelez toujours destroy() avant de supprimer définitivement le canvas. Dans les applications monopage, les hooks de nettoyage du framework sont l’emplacement approprié.

Les callbacks de disponibilité du framework confirment l’initialisation et l’installation initiale réussie des props, pas une trame de canevas peinte. React 19.2+ Activity en masquage conserve le renderer monté et sa mémoire jusqu’au démontage effectif ; ce n’est pas une frontière de disposal de worker. Voir le contrat de cycle de vie de l’adaptateur adapter lifecycle contract pour les refs masquées, les callbacks différés et la récupération d’erreur.