Open oeway opened 4 years ago
Hi @oeway ! For performance / stability reasons, we are currently throttling setImage
:
If we change this from 100
(maybe too conservative) to 10
or 20
, does that serve your use case?
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.
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.
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?
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.
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.
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.
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(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.