JiveXML events JiveXMLLoader.process() parses XML DOM synchronously:
Event switching EventDisplay.buildEventDataFromJSON() calls clearEventData() then buildEventData() both synchronous. The user sees a frozen UI between events.
Impact
This affects the core user interaction for every experiment (ATLAS, CMS, LHCb, TrackML). For small events it's imperceptible, but ATLAS events with dense track collections or TrackML events with ~100k hits cause multi-second freezes.
Proposed approach
Move the heavy parsing work off the main thread using Web Workers:
Phase 1 Worker-based parsing (lower risk):
Create a ParsingWorker that receives raw event data (JSON string or XML string) and returns structured, processed data ready for Three.js object creation:
The key insight is that the parsing + data extraction (the expensive part) can run in a worker, while Three.js object creation (which needs access to the WebGL context) must stay on the main thread but by that point the data is already structured and the object creation is fast.
Phase 2 Chunked processing with progress (optional):
For very large events, the worker could send partial results in chunks, allowing the main thread to show incremental loading progress:
Worker: postMessage({ type: 'progress', collection: 'Tracks', count: 5000 })
Worker: postMessage({ type: 'progress', collection: 'Hits', count: 95000 })
Worker: postMessage({ type: 'complete', data: fullProcessedEvent })
Considerations
- Web Workers cannot access the DOM or Three.js renderer only the pure data parsing should be offloaded
- Transferable objects (ArrayBuffer) should be used for large typed arrays to avoid copy overhead
- The worker needs access to the loader logic this may require refactoring loaders to separate "parse data" from "create 3D objects"
- Fallback: if Workers aren't available, the current synchronous path should still work
I'm happy to prototype Phase 1 for a single loader (e.g., PhoenixLoader) if there's interest.
Hello @EdwardMoyse and @sponce has Web Worker–based parsing been considered before? The existing architecture cleanly separates data loading (async) from data processing (sync), which makes the worker boundary relatively natural to introduce.
JiveXML events JiveXMLLoader.process() parses XML DOM synchronously:
Event switching EventDisplay.buildEventDataFromJSON() calls clearEventData() then buildEventData() both synchronous. The user sees a frozen UI between events.
Impact
This affects the core user interaction for every experiment (ATLAS, CMS, LHCb, TrackML). For small events it's imperceptible, but ATLAS events with dense track collections or TrackML events with ~100k hits cause multi-second freezes.
Proposed approach
Move the heavy parsing work off the main thread using Web Workers:
Phase 1 Worker-based parsing (lower risk):
Create a ParsingWorker that receives raw event data (JSON string or XML string) and returns structured, processed data ready for Three.js object creation:
The key insight is that the parsing + data extraction (the expensive part) can run in a worker, while Three.js object creation (which needs access to the WebGL context) must stay on the main thread but by that point the data is already structured and the object creation is fast.
Phase 2 Chunked processing with progress (optional):
For very large events, the worker could send partial results in chunks, allowing the main thread to show incremental loading progress:
Considerations
I'm happy to prototype Phase 1 for a single loader (e.g., PhoenixLoader) if there's interest.
Hello @EdwardMoyse and @sponce has Web Worker–based parsing been considered before? The existing architecture cleanly separates data loading (async) from data processing (sync), which makes the worker boundary relatively natural to introduce.