Workers, thread principal et rendu
Choisissez et faites fonctionner les voies de rendu Canvas2D partagées de Sixtyfold.
Sixtyfold dispose d’un seul modèle 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 construction du worker est bloquée de manière synchrone, y compris 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 rebasculera si le rendu en 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 tampons typés en vrac. C’est la voie préférée pour les 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 sur le thread principal, tels que le rendu de tooltip personnalisé, reçoivent des messages compacts du renderer plutôt qu’un accès direct à l’état du worker. Gardez les callbacks déterministes et rapides.
Mode thread principal
Utilisez renderMode: "main" pour les environnements de test, les navigateurs sans canvas transférable, les hôtes stricts qui interdisent les workers, ou pour des graphiques statiques plus petits où une intégration plus simple prime sur l’isolation du thread UI.
L’adaptateur sur le thread principal livre intentionnellement les messages du renderer de façon asynchrone. Ne supposez pas que l’appel à setData a synchroniquement complété sa première frame ; utilisez des statistiques ou une UI de disponibilité applicative quand l’achèvement d’une frame importe.
Les vérifications de release exercent Line et Stock via le thread principal et la voie auto utilisée par défaut dans Chromium, Firefox et WebKit. Sur les moteurs compatibles, auto utilise un worker OffscreenCanvas. Le contrat worker forcé est aussi testé dans Chromium. Cela vérifie la compatibilité, sans garantir une fréquence d’images indépendante de l’appareil.
Dimensionnement et DPR
Définissez la largeur et la hauteur CSS du canvas via le layout. Sixtyfold observe les changements de taille d’élément et de device-pixel-ratio, puis met à jour le backing store et le layout du renderer. resize() reste disponible lorsqu’un hôte change le layout d’une manière qui ne peut être observée immédiatement.
Évitez de ne régler que les attributs width et height du canvas pour des graphiques responsive. Ces attributs concernent le backing-store, alors que les tailles publiques et les champs de style de Sixtyfold 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 aveuglément. Les images superposées distantes nécessitent leur origine dans img-src et des en-têtes CORS compatibles.
Visibilité et nettoyage
Le graphique dans le navigateur met en pause ou évite les travaux inutiles lorsqu’il n’est pas visible. L’intervalle optionnel de maintien en vie pour Safari est désactivé par défaut et ne devrait être activé qu’après avoir reproduit la récupération des ressources sur les versions ciblées de Safari.
Appelez toujours destroy() avant de supprimer définitivement le canvas. Dans les applications single‑page, les hooks de nettoyage du framework sont le bon endroit.