itk-vtk-viewer icon indicating copy to clipboard operation
itk-vtk-viewer copied to clipboard

Calling setImage is laggy

Open oeway opened this issue 5 years ago • 7 comments

Hi, I am trying to use itk-vtk-viewer to display images updating in real-time, and I use viewer.setImage() to update it. The issue I have is that, when the function is called, the canvas doesn't necessary updated, the display constantly freeze. See an animation below updating_image-itk-vtk-viewer

(the number show later on the right is generated by console.log called right after viewer.setImage)

Is there a way to force the canvas to update? Do you have any suggestion for improving real-time performance? Thanks in advance.

oeway avatar Aug 24 '20 23:08 oeway

Hi @oeway ! For performance / stability reasons, we are currently throttling setImage:

https://github.com/Kitware/itk-vtk-viewer/blob/169a5ea34f891ae61318a876a484020a0c232162/src/createViewer.js#L432

If we change this from 100 (maybe too conservative) to 10 or 20, does that serve your use case?

thewtex avatar Sep 29 '20 17:09 thewtex

I would like to do as fast as possible, ideally without throttling, would that crash the viewer? Otherwise 10 might be already good enough for most cases.

oeway avatar Sep 29 '20 19:09 oeway

The units are in milliseconds; 10 would be 100 frames / second, which is already faster than a very smooth rendering rate, i.e. 60 fps. To avoid crashes, we should not go too high. Perceptually, it is hard to see any difference over 60 fps.

thewtex avatar Sep 29 '20 20:09 thewtex

The units are in milliseconds; 10 would be 100 frames / second, which is already faster than a very smooth rendering rate, i.e. 60 fps. To avoid crashes, we should not go too high. Perceptually, it is hard to see any difference over 60 fps.

I thought this is the interval between calls, that is to say, the actually rendering/display would take more time, no? Assume we set throttling to 0, the maximum frame rate we can achieve will be determined by the rendering which won't be very high for larger images.

Can we do throttling on the actual frame rate rather than the call to set_image?

Also does itk-vtk-viewer always rendering it immediately after calling set_image?

oeway avatar Sep 29 '20 20:09 oeway

Also does itk-vtk-viewer always rendering it immediately after calling set_image?

Yes -- render is performed after new data is added, so we need to take care to avoid trying to render at too rapid of a rate.

thewtex avatar Sep 30 '20 00:09 thewtex

Also does itk-vtk-viewer always rendering it immediately after calling set_image?

Yes -- render is performed after new data is added, so we need to take care to avoid trying to render at too rapid of a rate.

Sounds good.

oeway avatar Oct 03 '20 15:10 oeway

Theories discussed with @PaulHax include cloning to create a transferable when passing to worker threads when SharedArrayBuffer is not available. Architecture improvements could include keeping source data in a dedicated web worker.

thewtex avatar Jun 24 '22 20:06 thewtex