[vtk-developers] Failing test rendering problem

[Mathieu Westphal]

Also, another track could be investigated, the use of
vtkRenderWindow::SetOffScreenRendering remove the need of any Front/Bak
buffer fiddling, the image being always accessible.
However, it means we need to render it two times, one for the tester to
actually see the image, one for the offscreen renderring. it would look
like that in Testing.py:

    w2if = vtk.vtkWindowToImageFilter()
    # w2if.ReadFrontBufferOff() removing this
    renwin.Render() # adding this
    renwin.SetOffScreenRendering(1)  # and that
    w2if.SetInput(renwin)
    w2if.Update()
    compareImageWithSavedImage(w2if, img_fname, threshold)

But we may encounter some problem with the offscreen rendering,
(antialiasing? multisampling? i don't know much about it ).

What do you think ?

Mathieu Westphal

On Fri, Jul 3, 2015 at 10:34 AM, Mathieu Westphal <
mathieu.westphal at kitware.com> wrote:

> After further investigation, Joachim and me consider that the
> vtkTesting::FrontBuffer and associated argument "-FrontBuffer" to be
> basically useless, as one do not care if a test succeed using an image from
> the Front or the Back buffer, as long as a corresponding image can be found
> in any image buffer.
>
> Is anyone using this "-FrontBuffer" option ? If not we will deprecate it
> for further removal.
>
> it will allow to *always* check front and back buffer in vtkTesting, which
> is already the case when using static method vtkTesting::test.
> We propose this because there is a wrapping of vtkTesting which is
> massivelly used in Python test : vtkTclTest2Py/rtImageTest.py and may fail
> for the same reason explained before in this thread.
>
> And we think that removing the FrontBuffer option from vtkTesting is the
> right way to go here.
> It will not change the already proposed and working patch for Testing.py
> which do not use vtkTesting.
>
>
> Mathieu Westphal
>
> On Thu, Jul 2, 2015 at 5:28 PM, David Thompson <david.thompson at kitware.com
> > wrote:
>
>> > You may notice from git blame, those comments were added only
>> > recently, in October 2014 in commit e136e01e...
>> >
>> > I didn't even know when I did that commit that there was a python
>> > equivalent to vtkTesting.cxx. I wonder why vtkTesting.cxx isn't simply
>> > wrapped and used directly from python...?
>>
>> Python's unittest.TestCase framework is handy, familiar to Python users,
>> and breaks things into chunks that make running from an interpreter easier
>> than the traditional tests (since you can import a test module, create the
>> test instance, run setup, and manually run a test then tweak things from
>> the interpreter after the test has run).
>>
>> I do not oppose wrapping vtkTesting, but do oppose banishing the
>> vtk.test.vtkTest class.
>>
>>         David
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150703/c193c89a/attachment.html>