Suggestion: loading the dcm using a worker.

[Betalos]

I would like to suggest that the loading of the dicoms be within a worker (sometime loading a series with large number of instances would hang the UI). I am not sure is this the right place or the Tools repo, since the Tools repos that trigger the loading.

cornerstoneTools.addToolState(element, 'stack', stack); // [email protected]

[swederik]

Hi @Betalos,

I'm not sure I understand what you mean. The DICOM parsing and decoding is already in a Web Worker. What version of the WADO Image Loader are you using?

[Betalos]

hello @swederik, I meant the downloding (XHR request) (I am using 3.0.4).

[swederik]

Hmm... Doesn't the browser parallelize those already? I don't think you need to spin up a worker to make the XHR. Do you have any documentation or minimal example showing that this would have any impact?

[Betalos]

Well Yes, the browser would do parallelizing, but in front of large instances the UI would hang sometime (I am talking on some ct where the series holds more than 900 instances). For the example I try to make some one (I did one for an app of ours where I patch angularjs $http service)

[silencej]

I am also working on an issue related to a series with a lot of instances: when the user opens such a series in the first tab, and opens another in the second tab, the second one needs to wait for a long time (we have an API to fetch meta data first from the server, and this API uses the same domain as the image loader XHR, thus it is queued in the very end). TL; DR: Downloading a large of instances at once causes fetch being blocked.

In nutshell, I'd rather suggest we have a better downloading strategy for the large series. E.g. with a priority queue, so we can set the priority. Downloading images are apparently lower in priority than UI.