Unfortunately, the ForceImmediateUpdate idea does not work on my box...

On Thu, Sep 11, 2014 at 6:49 PM, Taylor Braun-Jones <[email protected]>
wrote:

> 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

Reply via email to