Files
star-map/src/app/shared/astro/routing.worker.ts
T
SenrokaiandClaude Opus 5 c6206a8311 Link only the stars that are drawn
The jump-link graph linked the whole catalogue: 3.7 million links at 8 pc, 7.4-7.8 s in the
worker and a 443-515 ms frame on the main thread when they landed, and most of them between stars
that were neither drawn nor clickable. A graph request now carries the star field's drawn stars,
and the worker links only those, over an index of its own with cells as wide as the range. The
scene asks again once a new drawn set has held still for 250 ms.

The renderer is handed the graph's bounding sphere instead of computing it: three.js walked every
vertex on the main thread in the first frame that drew a new graph, 48-55 ms at 8 pc.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
2026-09-17 16:16:38 +02:00

27 lines
1.1 KiB
TypeScript

/// <reference lib="webworker" />
import { answerRouting, indexCatalogue, RoutingCatalogue, RoutingRequest } from './routing';
import { StarNeighbourhood } from './star-neighbourhood';
/**
* Walks routes and builds the jump-link graph off the main thread. A search to a star 236 pc
* away, and the range it would need when there is none, can take seconds; a graph of the drawn
* stars at 8 pc is hundreds of thousands of links. On the page's own thread either stops the map
* for as long as it runs.
*/
let index: StarNeighbourhood | undefined;
addEventListener('message', ({ data }: MessageEvent<RoutingCatalogue | RoutingRequest>) => {
if (data.kind === 'catalogue') {
index = indexCatalogue(data);
return;
}
// The catalogue is always the first message, and a worker's messages arrive in order.
try {
const response = answerRouting(index!, data);
postMessage(response, response.kind === 'links' ? [response.segments.buffer] : []);
} catch (error) {
postMessage({ kind: 'failed', requestId: data.requestId, message: error instanceof Error ? error.message : String(error) });
}
});