Worker, Hauptthread und Rendering

Sixtyfold hat ein TypeScript Rendering‑Design mit drei Hosts: einen OffscreenCanvas Worker, einen asynchronen Hauptthread‑Adapter und den serverseitigen Rendering‑Einstiegspunkt. Canvas2D ist das einzige Grafik‑Backend.

Die Renderer-Auswahl gehört zu LineChartOptions und StockChartOptions. Den aufgelösten Modus liefert chart.getRenderMode().

Automatische Auswahl

renderMode: "auto" bevorzugt einen Worker, wenn der Browser Worker, OffscreenCanvas und Canvas‑Transfer unterstützt. Fehlt eine dieser Fähigkeiten oder wird die Worker‑Erstellung synchron blockiert (z. B. durch eine restriktive Content Security Policy), fällt es auf den Hauptthread zurück.

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

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

renderMode: "worker" drückt eine Präferenz, keine Zusicherung aus; es erfolgt weiterhin ein Fallback, wenn das Worker‑Rendering nicht starten kann. Verwenden Sie getRenderMode() für Telemetrie‑ und Supportinformationen.

Worker‑Modus

Im Worker‑Modus werden die Kontrolle über das Canvas und große typisierte Array‑Puffer übertragen. Dies ist der bevorzugte Pfad für interaktive Charts mit mehreren Millionen Punkten, da Hierarchieaufbau, Culling, Layout und Zeichnen die UI‑Aufgabe des Browsers nicht belegen.

Main‑Thread‑Callback‑Funktionen wie benutzerdefinierte Tooltip‑Renderings erhalten kompakte Renderer‑Nachrichten statt direkten Zugriff auf den Worker‑Zustand. Halten Sie Callbacks deterministisch und schnell.

Hauptthread‑Modus

Verwenden Sie renderMode: "main" für Testumgebungen, Browser ohne transferierbare Canvas, strikte Hosts, die Worker verbieten, oder kleinere statische Charts, bei denen einfachere Integration wichtiger ist als Isolation vom UI‑Thread.

Der Hauptthread‑Adapter liefert Renderer‑Nachrichten bewusst asynchron. Gehen Sie nicht davon aus, dass ein Aufruf von setData seinen ersten Frame synchron abgeschlossen hat; verwenden Sie Statistiken oder anwendungsseitige Readiness‑UI, wenn Frame‑Abschluss wichtig ist.

Release-Prüfungen testen Line und Stock sowohl über den Hauptthread als auch über den standardmäßigen auto-Pfad in Chromium, Firefox und WebKit. Auf kompatiblen Engines verwendet auto einen OffscreenCanvas-Worker. Der erzwungene Worker-Vertrag wird zusätzlich in Chromium geprüft. Das bestätigt die Kompatibilität, nicht eine geräteunabhängige Bildrate.

Größen und DPR

Setzen Sie die CSS‑Breite und -Höhe des Canvas über das Layout. Sixtyfold beobachtet Elementgröße und device‑pixel‑ratio‑Änderungen und aktualisiert dann Backing‑Store und Renderer‑Layout. resize() bleibt verfügbar, wenn ein Host das Layout auf eine Weise ändert, die nicht sofort beobachtet werden kann.

Vermeiden Sie es, nur die Canvas‑Attribute width und height für responsive Charts zu setzen. Diese Attribute sind Backing‑Store‑Werte, während Sixtyfolds öffentliche Größen‑ und Styling‑Felder CSS‑Pixel verwenden.

Content Security Policy

Eine restriktive Produktions‑Policy benötigt üblicherweise:

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

Passen Sie dieses Beispiel an die Anwendung an, statt es blind zu kopieren. Remote Overlay‑Bilder erfordern ihren Ursprung in img-src und kompatible CORS‑Antwortheader.

Sichtbarkeit und Aufräumen

Das Browser‑Chart pausiert oder vermeidet unnötige Arbeit, wenn es nicht sichtbar ist. Das optionale Safari‑Keep‑Alive‑Intervall ist standardmäßig deaktiviert und sollte nur aktiviert werden, nachdem die Ressourcenrückgewinnung auf den Ziel‑Safari‑Versionen reproduziert wurde.

Rufen Sie immer destroy() auf, bevor Sie das Canvas endgültig verwerfen. In Single‑Page‑Applications sind Framework‑Cleanup‑Hooks der richtige Ort.