Page MenuHomePhabricator

Some rendering tests fail due to timing issue
Closed, WontfixPublic


Taylor Braun-Jones identified this issue:

his fix is to add a delay of 100ms but we should consider to find a way to wait until the rendering thread is finished.

Event Timeline

User kolbch has pushed new remote branch:


[7dcb2b]: Merge branch 'bug-18083-AddDelayAfterRenderInRenderingTestHelper'

Merged commits:

2014-09-11 15:53:00 Christoph Kolb [bf0724]
replace delay by forceImmediateUpdate

2014-09-11 12:29:34 Christoph Kolb [3aa27c]
add delay after render, so the screenshot is only made when the scene is rendered completely

[b876be]: Merge branch 'bug-18083-AddDelayAfterRenderInRenderingTestHelper'

Merged commits:

2014-09-12 09:48:03 Christoph Kolb [d95205]
remove unneeded include

I tried the fix (the ForceImmediateUpdate() call) on my Ubuntu 14.04 system and I still had some rendering tests which failed. I also tried some combinations of forced updates and vtkRenderWindow calls (Finalize() etc.). None of it worked reliably, only a delay of 500ms with the method proposed by Taylor "fixed" all of the rendering tests.

also, the test still fails in the nightly, but locally i can only reproduce the error without the forceUpdate call.

I moved the forceUpdate after the render call and the rendering tests are now running on the linux continuous dartclient (ubuntu 14.04) without fails*.
If it also works on the nightlies, we should investigate the behavior of the RequestUpdate methods.

*except for the depth peeling test which seems not to be working in Xvfb

Sounds good. I think I didn't try the force update after the render call.

If the depth peeling test is Xvfb specific, we should just disable it for the cdash clients (there should be an option in the cdash script which allows to exclude certain tests - no need for if conditions in the main MITK CMake files).

Some rendering tests still fail on Christoph's nightly due to MITK's event handling (which is not used in VTK).

The effect is either that when the screenshot is taken, the render window does not have the correct size/resolution or the screenshot is completely black.

ForceImmediateUpdateAll and the delay somehow improve the situation but are not valid solutions to the problem.

This test fail on windows seems to be related:

the bunny is rendered, but the screenshot is black.

No recent fails as far as I know. If it comes up again, we can reopen it but I am currently out of approaches.

In my opinion we have much more pressing issues than randomly failing rendering tests. Rendering tests are important to show us if a rendering feature is globally broken after a change. It is not worth the effort to make all these tests run all the time. If they randomly make the continuous clients red, we can decide to disable them.

kislinsk added a project: Bulk Edit.
kislinsk removed a project: Bulk Edit.