Workers, thread principal e renderização

O Sixtyfold tem um design de renderização TypeScript com três anfitriões: um worker OffscreenCanvas, um adaptador assíncrono no thread principal e o ponto de entrada de renderização no servidor. Canvas2D é o único backend gráfico.

A seleção do renderer faz parte de LineChartOptions e StockChartOptions. O modo resolvido está disponível em chart.getRenderMode().

Seleção automática

renderMode: "auto" prefere um worker quando o navegador suporta Worker, OffscreenCanvas e transferência de canvas. Recorre ao thread principal quando essas capacidades faltam ou a construção do worker é bloqueada sincronicamente, inclusive por uma Content Security Policy restritiva.

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

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

renderMode: "worker" expressa uma preferência, não uma promessa; ainda recorre a fallback quando a renderização por worker não pode iniciar. Use getRenderMode() para telemetria e informação de suporte.

Modo worker

O modo worker transfere o controlo do canvas e buffers tipados em massa. É o caminho preferido para gráficos interativos com milhões de pontos porque a construção da hierarquia, culling, layout e desenho não ocupam a tarefa de UI do navegador.

Callbacks no thread principal, como renderização personalizada de tooltips, recebem mensagens compactas do renderer em vez de acesso direto ao estado do worker. Mantenha os callbacks determinísticos e rápidos.

Modo thread principal

Use renderMode: "main" para ambientes de teste, navegadores sem canvases transferíveis, anfitriões estritos que proíbem workers, ou gráficos estáticos menores em que a integração mais simples é mais importante do que o isolamento do thread de UI.

O adaptador do thread principal entrega intencionalmente mensagens do renderer de forma assíncrona. Não presuma que chamar setData completou sincronicamente o seu primeiro frame; use estatísticas ou UI de prontidão ao nível da aplicação quando a conclusão do frame for relevante.

As verificações de release exercitam Line e Stock através da thread principal e do caminho auto predefinido em Chromium, Firefox e WebKit. Nos motores compatíveis, auto usa um worker OffscreenCanvas. O contrato de worker forçado também é testado no Chromium. Isto verifica compatibilidade, não garante uma taxa de frames independente do dispositivo.

Dimensionamento e DPR

Defina a largura e altura em CSS do canvas através do layout. O Sixtyfold observa alterações de tamanho do elemento e do device-pixel-ratio, e depois atualiza o backing store e o layout do renderer. resize() permanece disponível quando um anfitrião muda o layout de forma que não possa ser observada imediatamente.

Evite definir apenas os atributos width e height do canvas para gráficos responsivos. Esses atributos são valores do backing-store, enquanto os campos públicos de tamanhos e estilos do Sixtyfold utilizam pixels CSS.

Content Security Policy

Uma política restritiva em produção normalmente necessita de:

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

Adapte este exemplo à aplicação em vez de o copiar cegamente. Imagens remotas de overlay exigem a sua origem em img-src e cabeçalhos CORS compatíveis na resposta.

Visibilidade e limpeza

O gráfico no navegador pausa ou evita trabalho desnecessário quando não está visível. O intervalo keep-alive opcional do Safari está desativado por padrão e só deve ser ativado depois de reproduzir a recuperação de recursos nas versões alvo do Safari.

Chame sempre destroy() antes de descartar permanentemente o canvas. Em aplicações single-page, os hooks de limpeza do framework são o local correto.