BUG: Fixed refresh rate computation in ctkVTKAbstractView

When ctkVTKAbstractView::scheduleRender calls decouples rendering requests from actual RenderWindow->Render() calls, to prevent repeated rendering pipeline updates when multiple Modified events are invoked in quick succession.

Minimum delay between RenderWindow->Render() calls was computed as

    double msecsBeforeRender = 100. / d->RenderWindow->GetDesiredUpdateRate();

instead of the proposed corrected formula:

    double msecsBeforeRender = 1000. / d->RenderWindow->GetDesiredUpdateRate();

Therefore, rendering requests are compressed when scheduleRender calls are 10x more than the desired update rate. Typically desired update rate is set to 30fps, which is approximately the screen refresh rate, therefore having a 10x multiplier (requests are started to be ignored over 300fps) is most likely a bug.

Most of the time interactor styles set DesiredUpdateRate to StillUpdateRate (=0.0001) when the view is not being rotated (which is most of the time). If DesiredUpdateRate < 0.01 (after the proposed modification: DesiredUpdateRate < 0.1) then the refresh rate is set to infinite (0 delay). Therefore, most of the time exact value of msecsBeforeRender is not used. Probably that is why the msecsBeforeRender computation error has not been discovered already.

Libs/Visualization/VTK/Widgets/ctkVTKAbstractView.cpp

@@ -185,7 +185,7 @@ void ctkVTKAbstractView::scheduleRender()
     return;
     }
 
-  double msecsBeforeRender = 100. / d->RenderWindow->GetDesiredUpdateRate();
+  double msecsBeforeRender = 1000. / d->RenderWindow->GetDesiredUpdateRate();
   if(d->VTKWidget->testAttribute(Qt::WA_WState_InPaintEvent))
     {
     // If the request comes from the system (widget exposed, resized...), the