Webworker #595

thewtex · 2018-02-19T03:00:16Z

This improves volume rendering initialization from 5.5 seconds to 2.1 seconds! ⚡

This cuts initial volume load time in half. Gradient computation occurs asynchronously in up to four web workers. These worker are built into the final bundle inline with worker-loader. VolumeMapper does not try to use the lightingTexture until after the gradients have been computed.

…arallel In web workers.

martinken · 2018-02-19T13:45:40Z

Can you change the test such that the new valid image is not needed? I would rather not add that valid image as it really isn't valid. It matches what I would expect the image to look like if the lighting/GO failed.

martinken · 2018-02-19T13:51:41Z

Sources/Rendering/OpenGL/VolumeMapper/index.js

+        computedGradientsRenderTimeout = setTimeout(
+          model.openGLRenderWindow.modified,
+          20
+        );


I'm not sure I get what this is doing in the timeout. Marking the renderWindow modified shouldn't change anything last I knew.

I should make a comment here, but this triggers a render after the gradients are ready.

jourdain · 2018-02-19T17:30:56Z

package.json

+    "seedrandom": "2.4.3",
+    "shelljs": "0.7.8",
+    "webworker-promise": "^0.4.1",
+    "worker-loader": "^1.1.0"


This is already provided inside kw-web-suite.

Good to know -- I will see if we can build without it.

jourdain · 2018-02-19T17:35:25Z

Sources/Interaction/Widgets/PiecewiseGaussianWidget/ComputeHistogram.worker.js

+
+registerWebworker(async ({ array, min, max, numberOfBins }, emit) => {
+  const delta = max - min;
+  const histogram = new Float32Array(numberOfBins);


Any reason for float32 instead of uint32?

Later, we normalize.

thewtex · 2018-02-19T21:30:43Z

Can you change the test such that the new valid image is not needed? I would rather not add that valid image as it really isn't valid. It matches what I would expect the image to look like if the lighting/GO failed.

I will see if capturing the rendering snapshot after a timeout delay is possible and does the trick.

thewtex · 2018-02-20T20:09:24Z

I will see if capturing the rendering snapshot after a timeout delay is possible and does the trick.

This does not work given the way that JavaScript executes code. The timeout is never reached.

@martinken Now, the volume mapper asynchronously re-renders with lighting effects enabled after the gradients have finished computing. If we really want to test this, I could try adding a .onLightingActivate or similarly named function to vtkVolumeMapper. This would be passed a callback that gets called when lighting is activated in vtkOpenGLVolumeMapper. In addition to re-rendering, this could grab a screen shot and perform the baseline comparison in the test. However, I am not sure how this should be exposed / propagated in vtkVolumeMapper and vtkOpenGLVolumeMapper. Thoughts?

martinken · 2018-02-20T20:39:39Z

Thinking about this more generally. We need to know when "stuff" is done. Imagine if we did image flips in a worker. For FDA approval we would really need to be able to tell the doctor, yeh the image flips have all been done and what you are looking at is correct. Sort of a pending-work-is-all-done check. Not sure how JS handles this normally.

One thought, maybe when situations like this arise we instead request animation from the interactor and when done we cancel animation.

For tests we setup a callback on render that checks some state and if ready captures the test image and returns. @jourdain thoughts?

jourdain · 2018-02-20T20:48:05Z

We need to have some kind of progress handler which does not necessarily tell you how much progress has been made but if there is some work going on and when a given work is completed.

Those async handling are usually handle via promises and in lot of my web apps I have a wrapper around those promise to capture/monitor the busy state. We just need to add similar infrastructure for vtk.js.

This is already brought in by kw-web-suite.

thewtex · 2018-02-20T21:20:44Z

@martinken @jourdain Yes, that sounds great. I am not sure how to implement it 😕 .

In the meantime, I looked into the callback approach, which could serve as a substitute until a promise-based render initialization infrastructure is in place. And, maybe this is used to inform the promise in the implementation? The test takes a bit longer to run, but it passes, and actually checks that lighting occurred :-). I will push the commit to the tip of this branch -- it could be omitted if desired.

This allows us to wait in the test to capture the render window after the gradients have been calculated, and lighting has been enabled on the volume.

jourdain · 2018-02-20T22:12:14Z

Sources/Rendering/Core/VolumeMapper/index.js

@@ -53,6 +54,7 @@ export function extend(publicAPI, model, initialValues = {}) {
    'imageSampleDistance',
    'maximumSamplesPerRay',
    'autoAdjustSampleDistances',
+    'onLightingActivated',


Use macro.event(publicAPI, model, 'lightingActivated') instead.

Nice. 🍬 Done.

jourdain · 2018-02-20T22:13:11Z

Sources/Rendering/OpenGL/VolumeMapper/index.js

+        const onLightingActivated = model.renderable.getOnLightingActivated();
+        if (typeof onLightingActivated === 'function') {
+          onLightingActivated();
+        }


With the event stuff, you will be able to call model.renderable.invokeLightingActivated().

jourdain · 2018-02-20T22:13:58Z

Sources/Rendering/OpenGL/VolumeMapper/test/testLighting.js

@@ -91,16 +90,18 @@ test.onlyIfWebGL('Test Lighted Volume Rendering', (t) => {
      renderer.getActiveCamera().zoom(1.4);
      renderer.resetCameraClippingRange();
      renderer.updateLightsGeometryToFollowCamera();
+      mapper.setOnLightingActivated(() => {


this will become mapper.onLightingActivated(() => {

jourdain · 2018-02-20T23:13:43Z

I'm guessing you validate the code with the event stuff?

jourdain · 2018-02-20T23:15:08Z

I'm also guessing that you haven't push yet...

thewtex · 2018-02-20T23:50:14Z

Not yet, now I am debugging a timeout...

These babel bugs are encountered when used in the Karma tests: babel/babel#6956 babel/babel#5085 Just explicitly return a Promise instead.

Use vtk.js event framework. Break invocation recursion. Avoid test timeout with `requestAnimation`.

thewtex · 2018-02-21T01:35:21Z

Ran into some interesting bugs, including a bug in babel:

babel/babel#5085

All good now 🍰

thewtex · 2018-02-21T15:16:33Z

Merci, @jourdain ! 🕺

thewtex added 2 commits February 18, 2018 21:54

perf(PiecewiseGaussianWidgets): Compute histogram asynchronously in p…

6537b63

…arallel In web workers.

martinken reviewed Feb 19, 2018

View reviewed changes

jourdain reviewed Feb 19, 2018

View reviewed changes

fix(Dependencies): Do not explicitly specify worker-loader

69b71ea

This is already brought in by kw-web-suite.

fix(VolumeMapper): Specify a callback to run after lighting activated

0913a11

This allows us to wait in the test to capture the render window after the gradients have been calculated, and lighting has been enabled on the volume.

thewtex force-pushed the webworker branch from 1d8833c to 0913a11 Compare February 20, 2018 21:41

jourdain reviewed Feb 20, 2018

View reviewed changes

thewtex added 2 commits February 20, 2018 20:13

fix(Workers): Do not use async keyword

2f6132d

These babel bugs are encountered when used in the Karma tests: babel/babel#6956 babel/babel#5085 Just explicitly return a Promise instead.

fix(VolumeMapper): Improve LightingActivated event invocation

0aee200

Use vtk.js event framework. Break invocation recursion. Avoid test timeout with `requestAnimation`.

jourdain merged commit 3edf520 into Kitware:master Feb 21, 2018

thewtex deleted the webworker branch February 21, 2018 13:30

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Webworker #595

Webworker #595

thewtex commented Feb 19, 2018

martinken commented Feb 19, 2018

martinken Feb 19, 2018

thewtex Feb 19, 2018

jourdain Feb 19, 2018

thewtex Feb 19, 2018

jourdain Feb 19, 2018

thewtex Feb 19, 2018

thewtex commented Feb 19, 2018

thewtex commented Feb 20, 2018

martinken commented Feb 20, 2018

jourdain commented Feb 20, 2018

thewtex commented Feb 20, 2018

jourdain Feb 20, 2018

thewtex Feb 20, 2018

jourdain Feb 20, 2018

thewtex Feb 20, 2018

jourdain Feb 20, 2018

thewtex Feb 20, 2018

jourdain commented Feb 20, 2018

jourdain commented Feb 20, 2018 •

edited

Loading

thewtex commented Feb 20, 2018

thewtex commented Feb 21, 2018

thewtex commented Feb 21, 2018

Webworker #595

Webworker #595

Conversation

thewtex commented Feb 19, 2018

martinken commented Feb 19, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thewtex commented Feb 19, 2018

thewtex commented Feb 20, 2018

martinken commented Feb 20, 2018

jourdain commented Feb 20, 2018

thewtex commented Feb 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jourdain commented Feb 20, 2018

jourdain commented Feb 20, 2018 • edited Loading

thewtex commented Feb 20, 2018

thewtex commented Feb 21, 2018

thewtex commented Feb 21, 2018

jourdain commented Feb 20, 2018 •

edited

Loading