DRACOLoader: Decoding should happen in a Web Worker.

Decoding Draco geometries is a long, blocking task, and shouldn’t be happening on the main thread. I’m hoping that with some of the LoaderSupport APIs we should be able to configure it to run just as easily in a web worker as not. Proposed API:


// Main thread
var loader1 = new THREE.DRACOLoader()
  // .setParser(new THREE.DRACOLoader.Parser()) // OPTIONAL
  .load('foo.drc',  () => {...});

// Web worker
var loader2 = new THREE.DRACOLoader()
  .setParser(new THREE.DRACOLoader.WWParser())
  .load('foo.drc', () => {...});

// GLTFLoader + WW
var dracoLoader = new THREE.DRACOLoader()
  .setParser(new THREE.DRACOLoader.WWParser());
var gltfLoader = new THREE.GLTFLoader()
  .load('foo.gltf', () => {...});

The distinction between Loader and Parser exists because the Parser cannot know about any THREE.* types, to minimize dependencies in the WW.

/cc @takahirox @kaisalmen

Aside — In a perfect world the WASM Draco decoder would use threading, but WASM doesn’t support that yet, and the decoder would need changes if it did, so using a web worker seems like the place to start.

Author: Fantashit

2 thoughts on “DRACOLoader: Decoding should happen in a Web Worker.

  1. No concern about hijacking it’s all very related. 😅

    I’ve been wanting to try DRACOLoader + workers for a while still haven’t gotten started… if you’re interested and find time please do! No time constraint.

  2. Perhaps the author (Matt Greenhalgh, Stink Studios – ping @mattg73) is able to share their implementation with the community as mentioned in their new technical case study: https://medium.com/@stinkstudios/creating-qalam-d016a0a52d56

    Our solution was to move the decompression task off the main thread using Web Workers. We had to modify the THREE.js Draco decoder to support this bespoke functionality. Our change stopped the main thread from being blocked during decompression but we instantly hit against another problem: the decompressed buffer sat in a different thread from the main thread that required it. Copying this data between threads created an even bigger lock-up while the large amount of data was transferred. We solved this problem by implementing a Transferable Objects solution that changes the buffer owner by pointer reference rather than moving the data between threads.

Comments are closed.