Hi,
a fix for this issue would be great!
Did you try any of the vtkRenderWindow methods like Finalize() or
WaitForCompletion() instead of manually introducing a delay?
Best,
Sascha
On 09/11/2014 12:46 PM, Christoph Kolb wrote:
Hi Taylor,
thank you for the fix! The tests were also failing on some of our
machines, so I created a bug and a branch with your solution:
http://bugs.mitk.org/show_bug.cgi?id=18083
If there is a more flexible way to wait for the renderer, then we
should of course do that. But just now I can't think of a better
solution than the delay.
Regards
Christoph
On 10.09.2014 22:48, Taylor Braun-Jones wrote:
Hi all,
I am seeing a timing issue with some rendering unit tests. On my box
(Intel Core i7, NVidia Quadro 4000, CentOS 7) the following tests fail:
144 - mitkPointSetVtkMapper2D_openMeAlone640x480 (Failed)
145 - mitkPointSetVtkMapper2D_Pic3DPointSetForPic3D640x480 (Failed)
146 - mitkPointSetVtkMapper2D_openMeAloneGlyphType640x480 (Failed)
147 - mitkPointSetVtkMapper2D_openMeAloneTransformed640x480 (Failed)
149 - mitkSurfaceDepthPeelingTransparency_StanfordBunnySTL640x480
(Failed)
150 - ResliceInterpolationIsLinear (Failed)
151 - ResliceInterpolationIsCubic (Failed)
154 - mitkTextOverlay2DRenderingTest_ball (Failed)
156 - mitkTextOverlay3DRendering3DTest_ball (Failed)
157 - mitkTextOverlay3DColorRenderingTest_ball (Failed)
160 - mitkSurfaceGLMapper2DColorTest_RedBall (Failed)
161 - mitkSurfaceGLMapper2DColorTest_DasArmeSchwein (Failed)
162 - mitkSurfaceGLMapper2DOpacityTest_BallOpacity (Failed)
Looking at the details of one test, ResliceInterpolationIsLinear,
showed that it was failing with this error:
...
CompareRenderWindowAgainstReference test result
positive?<DartMeasurement name="ImageError"
type="numeric/double">100000000000000005250476025520442024870446858110815915491585411551180245798890819578637137508044786404370444383288387817694252323536043057564479218478670698284838720092657580373783023379478809005936895323497079994508111903896764088007465274278014249457925878882005684283811566947219638686545940054016.000</DartMeasurement><DartMeasurement
name="BaselineImage"
type="text/string">Standard</DartMeasurement>Failed Image Test :
100000000000000005250476025520442024870446858110815915491585411551180245798890819578637137508044786404370444383288387817694252323536043057564479218478670698284838720092657580373783023379478809005936895323497079994508111903896764088007465274278014249457925878882005684283811566947219638686545940054016.000
Image differencing failed to produce an image because images are
different size:
Valid image: 639, 479, 0
Test image: 99, 99, 0
<DartMeasurement name="WallTime"
type="numeric/double">0.078</DartMeasurement>
<DartMeasurement name="CPUTime"
type="numeric/double">0.060</DartMeasurement>
[FAILED]
Putting the the following 100ms delay solves the issue for all the
failing tests for me:
bool mitk::RenderingTestHelper::CompareRenderWindowAgainstReference(int argc,
char* argv[], double threshold)
{
this->Render();
vtksys::SystemTools::Delay(100); // <-- Fixes the failing unit tests
// ...
}
But is this legit fix or is it just hiding a problem?
From empirical testing on my box 5ms was not sufficient but 10ms was
- so 100ms is very conservative. If I put in something very long like
3000 ms, I can see the rendered scene is in fact a very small portion
of the render window (about 100x100px like the error message states)
then right when the 3000 ms delay expires I very briefly see the
rendered image get stretched to the full size of the render window.
Thanks for any help,
Taylor
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
