Sounds good to me. Thanks for the quick turn around!
Just a note the change that made it into master: it unnecessarily added a
#include for vtksys/SystemTools.hxx.
On Thu, Sep 11, 2014 at 10:03 AM, Sascha Zelzer <[email protected]
> wrote:
> This looks definitely "nicer". I would suggest to merge these changes
> and let our CDash clients do the testing.
>
> - Sascha
>
>
> On 09/11/2014 03:57 PM, Christoph Kolb wrote:
>
> Neither of the methods are working. It seems that the vtk renderer is not
> really the issue, but the mitkVtkPropRenderer:
> The *mitk::VtkPropRenderer::Resize(int w, int h) *method only requests an
> update from the mitk::RenderingManager, which is apparently executed too
> late.
> I changed the quick fix in the branch to this:
>
> bool mitk::RenderingTestHelper::CompareRenderWindowAgainstReference(int
> argc, char* argv[], double threshold)
> {
> m_RenderWindow->GetRenderer()->ForceImmediateUpdate();
> this->Render();
> // No more delay after this point
> ...
>
> It works on my machine, but it would be good if someone else could test it.
>
> Regards
> Christoph
>
>
> On 11.09.2014 14:42, Sascha Zelzer wrote:
>
> 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
>
>
------------------------------------------------------------------------------
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
