Trabajadores, hilo principal y renderizado

Sixtyfold tiene un diseño de renderizado TypeScript con tres anfitriones: un worker OffscreenCanvas, un adaptador asíncrono en el main thread y el punto de entrada de renderizado del lado servidor. Canvas2D es el único backend gráfico.

La selección del renderizador forma parte de LineChartOptions y StockChartOptions. El modo resuelto está disponible mediante chart.getRenderMode().

Selección automática

renderMode: "auto" prefiere un worker cuando el navegador admite Worker, OffscreenCanvas y la transferencia de canvas. Recurre al main thread cuando faltan esas capacidades o la construcción del worker se bloquea sincrónicamente, incluso por una Content Security Policy restrictiva.

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

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

renderMode: "worker" expresa una preferencia, no una promesa; aún falla y cambia a la alternativa cuando el renderizado en worker no puede iniciarse. Use getRenderMode() para telemetría e información de soporte.

Modo worker

El modo worker transfiere el control del canvas y buffers tipados de gran tamaño. Es la ruta preferida para gráficos interactivos con millones de puntos porque la construcción de jerarquías, el culling, el layout y el dibujo no ocupan la tarea de interfaz de usuario del navegador.

Las devoluciones en el main thread, como el renderizado de tooltips personalizados, reciben mensajes compactos del renderizador en lugar de acceso directo al estado del worker. Mantenga las callbacks deterministas y rápidas.

Modo en hilo principal

Use renderMode: "main" para entornos de pruebas, navegadores sin canvas transferibles, hosts estrictos que prohíben workers o gráficos estáticos más pequeños donde una integración más simple es más importante que el aislamiento del UI-thread.

El adaptador del main-thread entrega intencionadamente los mensajes del renderizador de forma asíncrona. No suponga que llamar a setData ha completado sincrónicamente su primer frame; use estadísticas o una UI de preparación a nivel de aplicación cuando la finalización de frame importe.

Las comprobaciones de la versión ejercitan Line y Stock tanto por el hilo principal como por la ruta auto predeterminada en Chromium, Firefox y WebKit. En motores compatibles, auto usa un worker OffscreenCanvas. El contrato de worker forzado también se prueba en Chromium. Esto verifica la compatibilidad, no garantiza una tasa de fotogramas independiente del dispositivo.

Dimensionado y DPR

Establezca el ancho y alto CSS del canvas mediante el layout. Sixtyfold observa los cambios de tamaño del elemento y de device-pixel-ratio, y luego actualiza el backing store y el layout del renderizador. resize() sigue disponible cuando un anfitrión cambia el layout de una forma que no puede observarse inmediatamente.

Evite establecer únicamente los atributos width y height del canvas para gráficos responsivos. Esos atributos son valores del backing-store, mientras que los tamaños y campos de estilo públicos de Sixtyfold usan píxeles CSS.

Content Security Policy

Una política de producción restrictiva comúnmente necesita:

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

Adapte este ejemplo a la aplicación en lugar de copiarlo a ciegas. Las imágenes remotas de superposición requieren su origen en img-src y encabezados CORS compatibles.

Visibilidad y limpieza

El gráfico en el navegador pausa o evita trabajo innecesario cuando no es visible. El intervalo opcional de keep-alive de Safari está desactivado por defecto y solo debe habilitarse tras reproducir la reclamación de recursos en las versiones objetivo de Safari.

Llame siempre a destroy() antes de descartar permanentemente el canvas. En aplicaciones de una sola página, los hooks de limpieza del framework son el lugar correcto.