From elvis.stansvik at orexplore.com  Thu Jun  1 04:41:12 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Thu, 1 Jun 2017 10:41:12 +0200
Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with
 QVTKOpenGLWidget in 8.0.0.rc1
In-Reply-To: <CANXz0SaYdfSaksP-dLdb0n2C1RD3X2Ti3uiQNMXcw30pFCOiCw@mail.gmail.com>
References: <CAE-7VJky=1hS1GrwWjOo+xtN+usWmWRYSOxz_xC0LOZpTsQJWg@mail.gmail.com>
 <CAEcL5t5yCuq-ZMATypkCMcv=O7qXeUJeMLoHJDM1jYeHpW67jw@mail.gmail.com>
 <CAE-7VJncJ7iB8DBGLian25CRm=GHNnMfoP4+Pb2yBtKU2kknUQ@mail.gmail.com>
 <CAEcL5t4LOQZ+H7wfgEL3oSnX6EProzmss_2kL7+k9Hbd5y8oSQ@mail.gmail.com>
 <CAEcL5t6YomxS1ugVkyQ0L5X=uQFAqC9uK1pJwWCZqRutRHgnjA@mail.gmail.com>
 <CAE-7VJkxUyiVwpC6=5JdfGEwxtpvFEfLwBxadCJSZrET3tc_RA@mail.gmail.com>
 <CAE-7VJnzPH1D5X-xJQ+jHK1UjFG49Yb_-iuk2j0+fUTnEJGGZA@mail.gmail.com>
 <CAF2skS7pSPKqriq+rfsPTf=S+7+vuqXPuLB-O4AfAa1ZR38_Mw@mail.gmail.com>
 <CAE-7VJ=Jy5Y8iNiFxkO_2Rx2ZuoJMKSdCw5ZsUi63_ouHm7j_Q@mail.gmail.com>
 <CAKME8fHJ-0jCymCqyi=UYv2_HnQc2exUzg5p+RDEyfx=KTz4Zg@mail.gmail.com>
 <CAE-7VJngFnxZ7ia6Y3kqLKyZ1-T2DOVnc74eJXkZ+_3tw_71tw@mail.gmail.com>
 <CAE-7VJmB6wERryTW0SdkHD2LN_F_tHu2KgBFh5i8=3oCooG3+g@mail.gmail.com>
 <CAKME8fFrT0i3f-Mfq9q0Q2+TPE-suP7bd4X+HFECOyumJjNY=g@mail.gmail.com>
 <CAE-7VJnKXwjWCTHS3_-L_bezwTEUx24jHUyix8Ci7NkQrO5bWg@mail.gmail.com>
 <CANXz0SZC=Afg+sQggPsBcn9+BLbCQJ1+y0Cd2jJk1fUPW0iQxw@mail.gmail.com>
 <CAE-7VJkapY_mB6NFF5an6CpVLEZpvKpkopsgkmNXJ4SvpS+g+A@mail.gmail.com>
 <CANXz0SYXX-nrmq6jrRhJQ0jkosRTjvOh6_GyYkMaNQZKAWY33g@mail.gmail.com>
 <CAE-7VJmsL7DtLY=jXonCqxikxpU9045BS+P0zsQzAdzDbFCnSA@mail.gmail.com>
 <CANXz0SYOwoTtVHaoLkENLfoxw2jvUvTu=sMLV-EOuwJ2yXkC6w@mail.gmail.com>
 <CAE-7VJ==Ma59naju3Jc-Ymjqfmgv9TBzwxM9ivbgGQ9ujqcRYw@mail.gmail.com>
 <CANXz0SaYdfSaksP-dLdb0n2C1RD3X2Ti3uiQNMXcw30pFCOiCw@mail.gmail.com>
Message-ID: <CAE-7VJkSvPT2-tQvdQiCzS80PvUtzn9kFP7OzaX6gG5voBKOkg@mail.gmail.com>

2017-05-31 21:06 GMT+02:00 Ken Martin <ken.martin at kitware.com>:
> Are you setting window->SetMultisamples(0) as well early on?

I've now tried with window->SetMultisamples(0) as soon as the window
is constructed (updated test case below). Volumes are still not
showing up when running with QVTKOpenGLWidget, while with plain VTK
window it does :/

This is with Qt 5.6 branch patched as you suggested.

I think I'm running out of options :(

I've looked through reported PV issues (since the problem manifests
also there on this machine), and I believe this it:

    https://gitlab.kitware.com/paraview/paraview/issues/17461

That bug mentions Windows 10 explicitly, while I'm seeing it on
Windows 7, but I think that's just coincidental. And David Cole
reported being able to reproduce on Windows 8.1 / HD 4000.

I've looked through all VTK bugs and cannot find it reported. Do you
guys think it's time I report it?

Aron Heiser could not reproduce, but he was on HD 530, a much newer
(Skylake) chip and with a newer driver version (20-something), than
the reported cases. So probably this only occurs on certain Intel
driver versions / chips.

I think the Qt bad logic (QTBUG-60742) is a red herring in this case,
since I'm now running with a version that will always honor the exact
requested version.

Elvis


main.cpp:

#include <algorithm>

#include <vtkColorTransferFunction.h>
#include <vtkGenericOpenGLRenderWindow.h>
#include <vtkGPUVolumeRayCastMapper.h>
#include <vtkImageData.h>
#include <vtkNew.h>
#include <vtkPiecewiseFunction.h>
#include <vtkProperty.h>
#include <vtkRenderer.h>
#include <vtkRenderWindow.h>
#include <vtkRenderWindowInteractor.h>
#include <vtkVolume.h>
#include <vtkVolumeProperty.h>

#include <QVTKOpenGLWidget.h>

#include <QApplication>

int main(int argc, char *argv[])
{
    auto defaultFormat = QVTKOpenGLWidget::defaultFormat();
    defaultFormat.setSamples(0);
    QSurfaceFormat::setDefaultFormat(defaultFormat);

    QApplication app(argc, argv);

    // Set up volume rendering
    vtkNew<vtkColorTransferFunction> colorFunction;
    colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0);
    colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0);

    vtkNew<vtkPiecewiseFunction> opacityFunction;
    opacityFunction->AddPoint(0.0, 0.0);
    opacityFunction->AddPoint(1.0, 1.0);

    vtkNew<vtkImageData> imageData;
    imageData->SetExtent(0, 200, 0, 200, 0, 200);
    imageData->AllocateScalars(VTK_FLOAT, 1);
    std::fill_n(static_cast<float *>(imageData->GetScalarPointer()),
8000000, 0.01);

    vtkNew<vtkGPUVolumeRayCastMapper> volumeMapper;
    volumeMapper->SetInputData(imageData.Get());

    vtkNew<vtkVolumeProperty> volumeProperty;
    volumeProperty->SetScalarOpacity(opacityFunction.Get());
    volumeProperty->SetColor(colorFunction.Get());
    volumeProperty->ShadeOff();

    vtkNew<vtkVolume> volume;
    volume->SetMapper(volumeMapper.Get());
    volume->SetProperty(volumeProperty.Get());

    vtkNew<vtkRenderer> renderer;
    renderer->AddVolume(volume.Get());
    renderer->SetBackground(1.0, 1.0, 1.0);

    if (argc > 1) {
        // Render with QVTKOpenGLWidget
        vtkNew<vtkGenericOpenGLRenderWindow> window;
    window->SetMultiSamples(0);
        window->AddRenderer(renderer.Get());

        auto widget = new QVTKOpenGLWidget();
        widget->SetRenderWindow(window.Get());
        widget->show();

        return app.exec();
    } else {
        // Render with "plain" render window / interactor
        vtkNew<vtkRenderWindow> window;
    window->SetMultiSamples(0);
        window->AddRenderer(renderer.Get());

        vtkNew<vtkRenderWindowInteractor> interactor;
        interactor->SetRenderWindow(window.Get());
        interactor->Start();

        return 0;
    }
}


CMakeLists.txt:

cmake_minimum_required(VERSION 3.1)

project(TestCase)

find_package(VTK 8.0 COMPONENTS
    vtkCommonCore
    vtkCommonDataModel
    vtkCommonExecutionModel
    vtkCommonMath
    vtkFiltersSources
    vtkGUISupportQt
    vtkInteractionStyle
    vtkRenderingCore
    vtkRenderingOpenGL2
    vtkRenderingVolume
    vtkRenderingVolumeOpenGL2
    REQUIRED
)

find_package(Qt5Widgets REQUIRED)

add_executable(TestCase main.cpp)

target_link_libraries(TestCase PUBLIC
    vtkCommonCore
    vtkCommonDataModel
    vtkCommonExecutionModel
    vtkCommonMath
    vtkFiltersSources
    vtkGUISupportQt
    vtkInteractionStyle
    vtkRenderingCore
    vtkRenderingOpenGL2
    vtkRenderingVolume
    vtkRenderingVolumeOpenGL2
    Qt5::Widgets
)

target_include_directories(TestCase PUBLIC
    ${VTK_INCLUDE_DIRS}
)

target_compile_definitions(TestCase PUBLIC
    ${VTK_DEFINITIONS}
)

set_target_properties(TestCase PROPERTIES
    CXX_STANDARD 14
    CXX_STANDARD_REQUIRED ON
)

>
> On Wed, May 31, 2017 at 2:55 PM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
>>
>> 2017-05-31 18:53 GMT+02:00 Ken Martin <ken.martin at kitware.com>:
>> > If it is only VolumeRendering then it may be you are requesting
>> > Multisamples. What happens if you turn that off?
>>
>> Multisamples is turned off (see my test case in my initial mail):
>>
>>     auto defaultFormat = QVTKOpenGLWidget::defaultFormat();
>>     defaultFormat.setSamples(0);
>>     QSurfaceFormat::setDefaultFormat(defaultFormat);
>>
>> It would be great if you could try the test case out on the 4600
>> system where you said you had problems with PV 5.4. I think it would
>> help in narrowing down the issue.
>>
>> Make sure you run it with a parameter (e.g. "TestCase 1"), so that it
>> uses QVTKOpenGLWidget and not a plain render window/interactor.
>>
>> Elvis
>>
>> >
>> > On Wed, May 31, 2017 at 11:27 AM, Elvis Stansvik
>> > <elvis.stansvik at orexplore.com> wrote:
>> >>
>> >> 2017-05-26 14:35 GMT+02:00 Ken Martin <ken.martin at kitware.com>:
>> >> > If you have a build of QT I think you could change
>> >> >
>> >> >
>> >> >
>> >> > https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/qwindowsglcontext.cpp#L730
>> >> >
>> >> > const int requestedVersion = qMin((format.majorVersion() << 8) +
>> >> > format.minorVersion(),
>> >> > staticContext.defaultFormat.version);
>> >> >
>> >> > to be
>> >> >
>> >> > const int requestedVersion = (format.majorVersion() << 8) +
>> >> > format.minorVersion());
>> >> >
>> >> > and it would fix it for VTK/ParaView. Not sure if it has any other
>> >> > consequences for Qt or if it would hit some different issue though.
>> >> > Qt
>> >> > on
>> >> > windows does some tricky stuff to support OpenGL/Angle/ES2.
>> >>
>> >> I patched Qt (5.6 branch) like this and tried again, but no luck :(
>> >> Volumes still not showing up..
>> >>
>> >> ..and thinking about it, could this really have been the problem I was
>> >> seeing? If Qt wrongly gave back a lower-versioned context (because of
>> >> it's questionable logic), as described in the Qt bug report, then
>> >> wouldn't VTK error out from the failure to obtain the version it
>> >> requested? In my case, there's no output/error at all from VTK. It's
>> >> just that the volumes won't show up.
>> >>
>> >> Another render window where I just have a vtkChartXY does show up
>> >> fine. It's only the volume rendering that isn't working.
>> >>
>> >> Would be interesting if others who could reproduce could try patching
>> >> their Qt like this to see if it solves it.
>> >>
>> >> Elvis
>> >>
>> >> >
>> >> >
>> >> >
>> >> > On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik
>> >> > <elvis.stansvik at orexplore.com> wrote:
>> >> >>
>> >> >> 2017-05-26 2:24 GMT+02:00 Ken Martin <ken.martin at kitware.com>:
>> >> >> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure
>> >> >> > it
>> >> >> > is
>> >> >> > a
>> >> >> > Qt bug we already bumped into with Mesa. They have what looks to
>> >> >> > me
>> >> >> > like
>> >> >> > some odd bad logic on windows for creating a context where they
>> >> >> > will
>> >> >> > not
>> >> >> > give you a core context later than the latest compatibility
>> >> >> > context
>> >> >> > they
>> >> >> > can
>> >> >> > get. For some vendors that is fine but for others they only offer
>> >> >> > Comp
>> >> >> > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may
>> >> >> > support
>> >> >> > OpenGL 4 in Core mode, Qt restricts you to 3.0.  I suspect if they
>> >> >> > fixed
>> >> >> > that the issue would go away. I believe Ben filed a bug report
>> >> >> > with
>> >> >> > them
>> >> >> > (Qt) when he bumped into this when using Mesa on Windows.
>> >> >>
>> >> >> Ah yes, that could definitely be it. I found Ben's bug:
>> >> >>
>> >> >>     https://bugreports.qt.io/browse/QTBUG-60742
>> >> >>
>> >> >> The affected version is listed as 5.8.0, but I'm having trouble on
>> >> >> 5.6.2, so I guess the bad logic is there as well.
>> >> >>
>> >> >> So let's hope for a fix in Qt then. But in the meantime, is there
>> >> >> anything you can think if that I could do to work around it? I
>> >> >> really
>> >> >> want our application to work on these kinds of machines (the one I
>> >> >> have was picked as a sort of a baseline for us wrt to requirements).
>> >> >>
>> >> >> In the bug report Ben mentions hacking around it with
>> >> >> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not
>> >> >> using Mesa.
>> >> >>
>> >> >> Elvis
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik
>> >> >> > <elvis.stansvik at orexplore.com> wrote:
>> >> >> >>
>> >> >> >> 2017-05-25 23:37 GMT+02:00 David Cole <DLRdave at aol.com>:
>> >> >> >> > Yes, I ran it both ways.
>> >> >> >> >
>> >> >> >> > It works when run without the argument in the plain VTK render
>> >> >> >> > window,
>> >> >> >> > and it is broken (shows nothing) when run with an argument.
>> >> >> >>
>> >> >> >> Alright, that's good. Then we're seeing the same thing.
>> >> >> >>
>> >> >> >> > Seems like it's definitely related to older Intel drivers on
>> >> >> >> > Windows.
>> >> >> >>
>> >> >> >> Yes, probably.
>> >> >> >>
>> >> >> >> > Not sure if there is an updated driver available for my
>> >> >> >> > machine.
>> >> >> >> > Hesitant to try changing/updating it for other reasons, and
>> >> >> >> > sorry,
>> >> >> >> > can't sacrifice this machine's current state for the purpose of
>> >> >> >> > testing this out...
>> >> >> >>
>> >> >> >> No worries, I'm free to do as I please with the one I have, so
>> >> >> >> I'll
>> >> >> >> do
>> >> >> >> some experimenting with different drivers when I'm back on
>> >> >> >> Monday.
>> >> >> >>
>> >> >> >> Thanks to everyone trying this out.
>> >> >> >>
>> >> >> >> Elvis
>> >> >> >>
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > D
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik
>> >> >> >> > <elvis.stansvik at orexplore.com> wrote:
>> >> >> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik
>> >> >> >> >> <elvis.stansvik at orexplore.com>:
>> >> >> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole <DLRdave at aol.com>:
>> >> >> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop,
>> >> >> >> >>>> Windows
>> >> >> >> >>>> 8.1,
>> >> >> >> >>>> with an Intel HD Graphics 4000 running driver version
>> >> >> >> >>>> 10.18.10.3316.
>> >> >> >> >>>> I
>> >> >> >> >>>> get your TestCase app window with nothing but an empty
>> >> >> >> >>>> (white)
>> >> >> >> >>>> client
>> >> >> >> >>>> region.
>> >> >> >> >>>>
>> >> >> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL
>> >> >> >> >>>> using
>> >> >> >> >>>> VolumeSmartMapper works fine on this very same machine.
>> >> >> >> >>>>
>> >> >> >> >>>> Another data point...
>> >> >> >> >>
>> >> >> >> >> Just one more thing David, did you try also running the
>> >> >> >> >> example
>> >> >> >> >> without any argument on this machine? (That would make it use
>> >> >> >> >> a
>> >> >> >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would
>> >> >> >> >> be
>> >> >> >> >> interesting to know if the volume shows up then. That would
>> >> >> >> >> confirm
>> >> >> >> >> that the machine can show volumes using VTK 8+OpenGL2 backend,
>> >> >> >> >> just
>> >> >> >> >> not with QVTKOpenGLWidget, so would strengthen my theory that
>> >> >> >> >> it
>> >> >> >> >> has
>> >> >> >> >> something to do with the new QVTKOpenGLWidget.
>> >> >> >> >>
>> >> >> >> >> Elvis
>> >> >> >> >>
>> >> >> >> >>>
>> >> >> >> >>> Finally a reproduction, I was beginning to despair :) Thanks
>> >> >> >> >>> a
>> >> >> >> >>> lot
>> >> >> >> >>> David.
>> >> >> >> >>>
>> >> >> >> >>> And just to make sure, Aron, did you run the test case as
>> >> >> >> >>> "TestCase
>> >> >> >> >>> 1", with a parameter? That's the crucial thing, as otherwise
>> >> >> >> >>> it'll
>> >> >> >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor
>> >> >> >> >>> (not
>> >> >> >> >>> QVTKOpenGLWidget), and not exhibit the problem.
>> >> >> >> >>>
>> >> >> >> >>> Elvis
>> >> >> >> >>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> D
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>>
>> >> >> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik
>> >> >> >> >>>> <elvis.stansvik at orexplore.com> wrote:
>> >> >> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser
>> >> >> >> >>>>> <aron.helser at kitware.com>:
>> >> >> >> >>>>>> Hi Elvis,
>> >> >> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an
>> >> >> >> >>>>>> Optimus
>> >> >> >> >>>>>> setup - both
>> >> >> >> >>>>>> intel and nvidia graphics.
>> >> >> >> >>>>>> With your test case, I'm able to see the volume running
>> >> >> >> >>>>>> either
>> >> >> >> >>>>>> with
>> >> >> >> >>>>>> Intel or
>> >> >> >> >>>>>> nVidia, so it doesn't repro for me.
>> >> >> >> >>>>>> I've got Intel HD530 graphics, with driver version
>> >> >> >> >>>>>> 21.20.16.4627
>> >> >> >> >>>>>> Sorry,
>> >> >> >> >>>>>> Aron
>> >> >> >> >>>>>
>> >> >> >> >>>>> Alright, bugger. Thanks for testing though!
>> >> >> >> >>>>>
>> >> >> >> >>>>> I won't be at the office until Monday again, but when I'm
>> >> >> >> >>>>> back
>> >> >> >> >>>>> I'll
>> >> >> >> >>>>> try experimenting with different driver versions.
>> >> >> >> >>>>>
>> >> >> >> >>>>> Elvis
>> >> >> >> >>>>>
>> >> >> >> >>>>>>
>> >> >> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik
>> >> >> >> >>>>>> <elvis.stansvik at orexplore.com> wrote:
>> >> >> >> >>>>>>>
>> >> >> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik
>> >> >> >> >>>>>>> <elvis.stansvik at orexplore.com>:
>> >> >> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri
>> >> >> >> >>>>>>> > <sankhesh.jhaveri at kitware.com>:
>> >> >> >> >>>>>>> >> Hi Elvis,
>> >> >> >> >>>>>>> >>
>> >> >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue.
>> >> >> >> >>>>>>> >> :(
>> >> >> >> >>>>>>> >>
>> >> >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics
>> >> >> >> >>>>>>> >> card
>> >> >> >> >>>>>>> >> but
>> >> >> >> >>>>>>> >> tried
>> >> >> >> >>>>>>> >> ParaView on a couple of se Windows machines as well as
>> >> >> >> >>>>>>> >> a
>> >> >> >> >>>>>>> >> Mac
>> >> >> >> >>>>>>> >> (with an
>> >> >> >> >>>>>>> >> Intel
>> >> >> >> >>>>>>> >> HD5600). Worked fine.
>> >> >> >> >>>>>>> >
>> >> >> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows
>> >> >> >> >>>>>>> > 7
>> >> >> >> >>>>>>> > machine with
>> >> >> >> >>>>>>> > Intel graphics? Would be great if someone could
>> >> >> >> >>>>>>> > reproduce.
>> >> >> >> >>>>>>>
>> >> >> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce
>> >> >> >> >>>>>>> Sankhesh.
>> >> >> >> >>>>>>>
>> >> >> >> >>>>>>> I've now put up the compiled self-contained test case
>> >> >> >> >>>>>>> here:
>> >> >> >> >>>>>>>
>> >> >> >> >>>>>>>     http://dose.se/~estan/voltestcase-inst.zip (18 MB)
>> >> >> >> >>>>>>>
>> >> >> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible)
>> >> >> >> >>>>>>> +
>> >> >> >> >>>>>>> Intel
>> >> >> >> >>>>>>> graphics could try running this test case with "TestCase
>> >> >> >> >>>>>>> 1"
>> >> >> >> >>>>>>> and
>> >> >> >> >>>>>>> see if
>> >> >> >> >>>>>>> the volume shows up, that would be great.
>> >> >> >> >>>>>>>
>> >> >> >> >>>>>>> (Running the test case with argc > 2 will make it use
>> >> >> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble).
>> >> >> >> >>>>>>>
>> >> >> >> >>>>>>> Elvis
>> >> >> >> >>>>>>>
>> >> >> >> >>>>>>> >
>> >> >> >> >>>>>>> > I could put up my build of the test case as a
>> >> >> >> >>>>>>> > self-contained
>> >> >> >> >>>>>>> > .zip, to
>> >> >> >> >>>>>>> > make it easy to test.
>> >> >> >> >>>>>>> >
>> >> >> >> >>>>>>> >>
>> >> >> >> >>>>>>> >> At this point, I am inclined to think that the
>> >> >> >> >>>>>>> >> graphics
>> >> >> >> >>>>>>> >> drivers
>> >> >> >> >>>>>>> >> on your
>> >> >> >> >>>>>>> >> Windows machine may need updating.
>> >> >> >> >>>>>>> >
>> >> >> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget,
>> >> >> >> >>>>>>> > and
>> >> >> >> >>>>>>> > just
>> >> >> >> >>>>>>> > use a
>> >> >> >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor.
>> >> >> >> >>>>>>> > Wouldn't
>> >> >> >> >>>>>>> > that
>> >> >> >> >>>>>>> > suggest that the drivers are capable enough, and that
>> >> >> >> >>>>>>> > the
>> >> >> >> >>>>>>> > problem is
>> >> >> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)?
>> >> >> >> >>>>>>> >
>> >> >> >> >>>>>>> > Elvis
>> >> >> >> >>>>>>> >
>> >> >> >> >>>>>>> >>
>> >> >> >> >>>>>>> >>
>> >> >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri
>> >> >> >> >>>>>>> >> <sankhesh.jhaveri at kitware.com> wrote:
>> >> >> >> >>>>>>> >>>
>> >> >> >> >>>>>>> >>> Okay thanks.
>> >> >> >> >>>>>>> >>>
>> >> >> >> >>>>>>> >>> I?ll take a look.
>> >> >> >> >>>>>>> >>>
>> >> >> >> >>>>>>> >>>
>> >> >> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik
>> >> >> >> >>>>>>> >>> <elvis.stansvik at orexplore.com> wrote:
>> >> >> >> >>>>>>> >>>>
>> >> >> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri
>> >> >> >> >>>>>>> >>>> <sankhesh.jhaveri at kitware.com>:
>> >> >> >> >>>>>>> >>>> > Hi Elvis,
>> >> >> >> >>>>>>> >>>> >
>> >> >> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly
>> >> >> >> >>>>>>> >>>> > binary
>> >> >> >> >>>>>>> >>>> > and
>> >> >> >> >>>>>>> >>>> > test
>> >> >> >> >>>>>>> >>>> > volume
>> >> >> >> >>>>>>> >>>> > rendering there? You can use the wavelet source
>> >> >> >> >>>>>>> >>>> > for a
>> >> >> >> >>>>>>> >>>> > test
>> >> >> >> >>>>>>> >>>> > dataset.
>> >> >> >> >>>>>>> >>>> > ParaView
>> >> >> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good
>> >> >> >> >>>>>>> >>>> > test
>> >> >> >> >>>>>>> >>>> > before diving
>> >> >> >> >>>>>>> >>>> > into the
>> >> >> >> >>>>>>> >>>> > code.
>> >> >> >> >>>>>>> >>>>
>> >> >> >> >>>>>>> >>>> I tried the wavelet example with Paraview
>> >> >> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603
>> >> >> >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal
>> >> >> >> >>>>>>> >>>> test
>> >> >> >> >>>>>>> >>>> case. The
>> >> >> >> >>>>>>> >>>> volume won't show up.
>> >> >> >> >>>>>>> >>>>
>> >> >> >> >>>>>>> >>>> It does show up if I switch to the software based
>> >> >> >> >>>>>>> >>>> ray
>> >> >> >> >>>>>>> >>>> cast
>> >> >> >> >>>>>>> >>>> mapper
>> >> >> >> >>>>>>> >>>> (but
>> >> >> >> >>>>>>> >>>> not with GPU or smart, which I guess both result in
>> >> >> >> >>>>>>> >>>> the
>> >> >> >> >>>>>>> >>>> GPU
>> >> >> >> >>>>>>> >>>> one being
>> >> >> >> >>>>>>> >>>> used).
>> >> >> >> >>>>>>> >>>>
>> >> >> >> >>>>>>> >>>> Please tell me if there's anything else I can do to
>> >> >> >> >>>>>>> >>>> help
>> >> >> >> >>>>>>> >>>> debugging.
>> >> >> >> >>>>>>> >>>> There are no errors printed when I run my test case.
>> >> >> >> >>>>>>> >>>>
>> >> >> >> >>>>>>> >>>> Elvis
>> >> >> >> >>>>>>> >>>>
>> >> >> >> >>>>>>> >>>> >
>> >> >> >> >>>>>>> >>>> > Thanks,
>> >> >> >> >>>>>>> >>>> > Sankhesh
>> >> >> >> >>>>>>> >>>> >
>> >> >> >> >>>>>>> >>>> >
>> >> >> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik
>> >> >> >> >>>>>>> >>>> > <elvis.stansvik at orexplore.com> wrote:
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> Hi all,
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get
>> >> >> >> >>>>>>> >>>> >> volumes
>> >> >> >> >>>>>>> >>>> >> rendered using
>> >> >> >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows
>> >> >> >> >>>>>>> >>>> >> 7,
>> >> >> >> >>>>>>> >>>> >> Intel
>> >> >> >> >>>>>>> >>>> >> graphics
>> >> >> >> >>>>>>> >>>> >> (HD
>> >> >> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show
>> >> >> >> >>>>>>> >>>> >> up
>> >> >> >> >>>>>>> >>>> >> fine
>> >> >> >> >>>>>>> >>>> >> on
>> >> >> >> >>>>>>> >>>> >> Windows 7
>> >> >> >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried
>> >> >> >> >>>>>>> >>>> >> turning
>> >> >> >> >>>>>>> >>>> >> off
>> >> >> >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default
>> >> >> >> >>>>>>> >>>> >> QSurfaceFormat.
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See
>> >> >> >> >>>>>>> >>>> >> the
>> >> >> >> >>>>>>> >>>> >> attached
>> >> >> >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and
>> >> >> >> >>>>>>> >>>> >> "TestCase
>> >> >> >> >>>>>>> >>>> >> 1"
>> >> >> >> >>>>>>> >>>> >> (right).
>> >> >> >> >>>>>>> >>>> >> The former uses a plain render window while the
>> >> >> >> >>>>>>> >>>> >> latter
>> >> >> >> >>>>>>> >>>> >> uses the
>> >> >> >> >>>>>>> >>>> >> new
>> >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7
>> >> >> >> >>>>>>> >>>> >> screenshot,
>> >> >> >> >>>>>>> >>>> >> the
>> >> >> >> >>>>>>> >>>> >> plain
>> >> >> >> >>>>>>> >>>> >> VTK rendering works fine, but the
>> >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget
>> >> >> >> >>>>>>> >>>> >> one
>> >> >> >> >>>>>>> >>>> >> is
>> >> >> >> >>>>>>> >>>> >> not
>> >> >> >> >>>>>>> >>>> >> showing
>> >> >> >> >>>>>>> >>>> >> the volume.
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> Versions used:
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04
>> >> >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2
>> >> >> >> >>>>>>> >>>> >> Qt 5.5.1
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> Windows 7
>> >> >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2
>> >> >> >> >>>>>>> >>>> >> Qt 5.6.2
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> Any ideas what the problem might be?
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of
>> >> >> >> >>>>>>> >>>> >> my
>> >> >> >> >>>>>>> >>>> >> build
>> >> >> >> >>>>>>> >>>> >> of the
>> >> >> >> >>>>>>> >>>> >> test
>> >> >> >> >>>>>>> >>>> >> case if you want.
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha
>> >> >> >> >>>>>>> >>>> >> issue I
>> >> >> >> >>>>>>> >>>> >> reported
>> >> >> >> >>>>>>> >>>> >> and
>> >> >> >> >>>>>>> >>>> >> got solved in my other thread.
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> Many thanks in advance,
>> >> >> >> >>>>>>> >>>> >> Elvis
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> main.cpp:
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> #include <algorithm>
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> #include <vtkColorTransferFunction.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkGenericOpenGLRenderWindow.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkGPUVolumeRayCastMapper.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkImageData.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkNew.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkPiecewiseFunction.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkProperty.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkRenderer.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkRenderWindow.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkRenderWindowInteractor.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkVolume.h>
>> >> >> >> >>>>>>> >>>> >> #include <vtkVolumeProperty.h>
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> #include <QVTKOpenGLWidget.h>
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> #include <QApplication>
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> int main(int argc, char *argv[])
>> >> >> >> >>>>>>> >>>> >> {
>> >> >> >> >>>>>>> >>>> >>     auto defaultFormat =
>> >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat();
>> >> >> >> >>>>>>> >>>> >>     defaultFormat.setSamples(0);
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat);
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>     QApplication app(argc, argv);
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>     // Set up volume rendering
>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkColorTransferFunction>
>> >> >> >> >>>>>>> >>>> >> colorFunction;
>> >> >> >> >>>>>>> >>>> >>     colorFunction->AddRGBPoint(0.0, 0.0, 0.0,
>> >> >> >> >>>>>>> >>>> >> 0.0);
>> >> >> >> >>>>>>> >>>> >>     colorFunction->AddRGBPoint(1.0, 0.0, 0.0,
>> >> >> >> >>>>>>> >>>> >> 0.0);
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkPiecewiseFunction> opacityFunction;
>> >> >> >> >>>>>>> >>>> >>     opacityFunction->AddPoint(0.0, 0.0);
>> >> >> >> >>>>>>> >>>> >>     opacityFunction->AddPoint(1.0, 1.0);
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkImageData> imageData;
>> >> >> >> >>>>>>> >>>> >>     imageData->SetExtent(0, 200, 0, 200, 0, 200);
>> >> >> >> >>>>>>> >>>> >>     imageData->AllocateScalars(VTK_FLOAT, 1);
>> >> >> >> >>>>>>> >>>> >>     std::fill_n(static_cast<float
>> >> >> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()),
>> >> >> >> >>>>>>> >>>> >> 8000000, 0.01);
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkGPUVolumeRayCastMapper>
>> >> >> >> >>>>>>> >>>> >> volumeMapper;
>> >> >> >> >>>>>>> >>>> >>     volumeMapper->SetInputData(imageData.Get());
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkVolumeProperty> volumeProperty;
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get());
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get());
>> >> >> >> >>>>>>> >>>> >>     volumeProperty->ShadeOff();
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkVolume> volume;
>> >> >> >> >>>>>>> >>>> >>     volume->SetMapper(volumeMapper.Get());
>> >> >> >> >>>>>>> >>>> >>     volume->SetProperty(volumeProperty.Get());
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkRenderer> renderer;
>> >> >> >> >>>>>>> >>>> >>     renderer->AddVolume(volume.Get());
>> >> >> >> >>>>>>> >>>> >>     renderer->SetBackground(1.0, 1.0, 1.0);
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>     if (argc > 1) {
>> >> >> >> >>>>>>> >>>> >>         // Render with QVTKOpenGLWidget
>> >> >> >> >>>>>>> >>>> >>         vtkNew<vtkGenericOpenGLRenderWindow>
>> >> >> >> >>>>>>> >>>> >> window;
>> >> >> >> >>>>>>> >>>> >>         window->AddRenderer(renderer.Get());
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>         auto widget = new QVTKOpenGLWidget();
>> >> >> >> >>>>>>> >>>> >>         widget->SetRenderWindow(window.Get());
>> >> >> >> >>>>>>> >>>> >>         widget->show();
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>         return app.exec();
>> >> >> >> >>>>>>> >>>> >>     } else {
>> >> >> >> >>>>>>> >>>> >>         // Render with "plain" render window /
>> >> >> >> >>>>>>> >>>> >> interactor
>> >> >> >> >>>>>>> >>>> >>         vtkNew<vtkRenderWindow> window;
>> >> >> >> >>>>>>> >>>> >>         window->AddRenderer(renderer.Get());
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>         vtkNew<vtkRenderWindowInteractor>
>> >> >> >> >>>>>>> >>>> >> interactor;
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get());
>> >> >> >> >>>>>>> >>>> >>         interactor->Start();
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>         return 0;
>> >> >> >> >>>>>>> >>>> >>     }
>> >> >> >> >>>>>>> >>>> >> }
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> CMakeLists.txt:
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1)
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> project(TestCase)
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS
>> >> >> >> >>>>>>> >>>> >>     vtkCommonCore
>> >> >> >> >>>>>>> >>>> >>     vtkCommonDataModel
>> >> >> >> >>>>>>> >>>> >>     vtkCommonExecutionModel
>> >> >> >> >>>>>>> >>>> >>     vtkCommonMath
>> >> >> >> >>>>>>> >>>> >>     vtkFiltersSources
>> >> >> >> >>>>>>> >>>> >>     vtkGUISupportQt
>> >> >> >> >>>>>>> >>>> >>     vtkInteractionStyle
>> >> >> >> >>>>>>> >>>> >>     vtkRenderingCore
>> >> >> >> >>>>>>> >>>> >>     vtkRenderingOpenGL2
>> >> >> >> >>>>>>> >>>> >>     vtkRenderingVolume
>> >> >> >> >>>>>>> >>>> >>     vtkRenderingVolumeOpenGL2
>> >> >> >> >>>>>>> >>>> >>     REQUIRED
>> >> >> >> >>>>>>> >>>> >> )
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED)
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp)
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC
>> >> >> >> >>>>>>> >>>> >>     vtkCommonCore
>> >> >> >> >>>>>>> >>>> >>     vtkCommonDataModel
>> >> >> >> >>>>>>> >>>> >>     vtkCommonExecutionModel
>> >> >> >> >>>>>>> >>>> >>     vtkCommonMath
>> >> >> >> >>>>>>> >>>> >>     vtkFiltersSources
>> >> >> >> >>>>>>> >>>> >>     vtkGUISupportQt
>> >> >> >> >>>>>>> >>>> >>     vtkInteractionStyle
>> >> >> >> >>>>>>> >>>> >>     vtkRenderingCore
>> >> >> >> >>>>>>> >>>> >>     vtkRenderingOpenGL2
>> >> >> >> >>>>>>> >>>> >>     vtkRenderingVolume
>> >> >> >> >>>>>>> >>>> >>     vtkRenderingVolumeOpenGL2
>> >> >> >> >>>>>>> >>>> >>     Qt5::Widgets
>> >> >> >> >>>>>>> >>>> >> )
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC
>> >> >> >> >>>>>>> >>>> >>     ${VTK_INCLUDE_DIRS}
>> >> >> >> >>>>>>> >>>> >> )
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC
>> >> >> >> >>>>>>> >>>> >>     ${VTK_DEFINITIONS}
>> >> >> >> >>>>>>> >>>> >> )
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES
>> >> >> >> >>>>>>> >>>> >>     CXX_STANDARD 14
>> >> >> >> >>>>>>> >>>> >>     CXX_STANDARD_REQUIRED ON
>> >> >> >> >>>>>>> >>>> >> )
>> >> >> >> >>>>>>> >>>> >> _______________________________________________
>> >> >> >> >>>>>>> >>>> >> 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
>> >> >> >> >>>>>>> >>>> >>
>> >> >> >> >>>>>>> >>>> > --
>> >> >> >> >>>>>>> >>>> >
>> >> >> >> >>>>>>> >>>> > Sankhesh Jhaveri
>> >> >> >> >>>>>>> >>>> >
>> >> >> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware |
>> >> >> >> >>>>>>> >>>> > (518)
>> >> >> >> >>>>>>> >>>> > 881-4417
>> >> >> >> >>>>>>> >>>
>> >> >> >> >>>>>>> >>> --
>> >> >> >> >>>>>>> >>>
>> >> >> >> >>>>>>> >>> Sankhesh Jhaveri
>> >> >> >> >>>>>>> >>>
>> >> >> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518)
>> >> >> >> >>>>>>> >>> 881-4417
>> >> >> >> >>>>>>> >>
>> >> >> >> >>>>>>> >> --
>> >> >> >> >>>>>>> >>
>> >> >> >> >>>>>>> >> Sankhesh Jhaveri
>> >> >> >> >>>>>>> >>
>> >> >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518)
>> >> >> >> >>>>>>> >> 881-4417
>> >> >> >> >>>>>>> _______________________________________________
>> >> >> >> >>>>>>> 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
>> >> >> >> >>>>>>>
>> >> >> >> >>>>>>
>> >> >> >> >>>>> _______________________________________________
>> >> >> >> >>>>> 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
>> >> >> >> >>>>>
>> >> >> >> _______________________________________________
>> >> >> >> 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
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Ken Martin PhD
>> >> >> > Distinguished Engineer
>> >> >> > Kitware Inc.
>> >> >> > 28 Corporate Drive
>> >> >> > Clifton Park NY 12065
>> >> >> >
>> >> >> > This communication, including all attachments, contains
>> >> >> > confidential
>> >> >> > and
>> >> >> > legally privileged information, and it is intended only for the
>> >> >> > use
>> >> >> > of
>> >> >> > the
>> >> >> > addressee.  Access to this email by anyone else is unauthorized.
>> >> >> > If
>> >> >> > you
>> >> >> > are
>> >> >> > not the intended recipient, any disclosure, copying, distribution
>> >> >> > or
>> >> >> > any
>> >> >> > action taken in reliance on it is prohibited and may be unlawful.
>> >> >> > If
>> >> >> > you
>> >> >> > received this communication in error please notify us immediately
>> >> >> > and
>> >> >> > destroy the original message.  Thank you.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Ken Martin PhD
>> >> > Distinguished Engineer
>> >> > Kitware Inc.
>> >> > 28 Corporate Drive
>> >> > Clifton Park NY 12065
>> >> >
>> >> > This communication, including all attachments, contains confidential
>> >> > and
>> >> > legally privileged information, and it is intended only for the use
>> >> > of
>> >> > the
>> >> > addressee.  Access to this email by anyone else is unauthorized. If
>> >> > you
>> >> > are
>> >> > not the intended recipient, any disclosure, copying, distribution or
>> >> > any
>> >> > action taken in reliance on it is prohibited and may be unlawful. If
>> >> > you
>> >> > received this communication in error please notify us immediately and
>> >> > destroy the original message.  Thank you.
>> >
>> >
>> >
>> >
>> > --
>> > Ken Martin PhD
>> > Distinguished Engineer
>> > Kitware Inc.
>> > 28 Corporate Drive
>> > Clifton Park NY 12065
>> >
>> > This communication, including all attachments, contains confidential and
>> > legally privileged information, and it is intended only for the use of
>> > the
>> > addressee.  Access to this email by anyone else is unauthorized. If you
>> > are
>> > not the intended recipient, any disclosure, copying, distribution or any
>> > action taken in reliance on it is prohibited and may be unlawful. If you
>> > received this communication in error please notify us immediately and
>> > destroy the original message.  Thank you.
>
>
>
>
> --
> Ken Martin PhD
> Distinguished Engineer
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.

From elvis.stansvik at orexplore.com  Thu Jun  1 05:25:37 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Thu, 1 Jun 2017 11:25:37 +0200
Subject: [vtk-developers] Volume won't show on Win7/Intel HD4600 with
 QVTKOpenGLWidget in 8.0.0.rc1
In-Reply-To: <CAE-7VJkSvPT2-tQvdQiCzS80PvUtzn9kFP7OzaX6gG5voBKOkg@mail.gmail.com>
References: <CAE-7VJky=1hS1GrwWjOo+xtN+usWmWRYSOxz_xC0LOZpTsQJWg@mail.gmail.com>
 <CAEcL5t5yCuq-ZMATypkCMcv=O7qXeUJeMLoHJDM1jYeHpW67jw@mail.gmail.com>
 <CAE-7VJncJ7iB8DBGLian25CRm=GHNnMfoP4+Pb2yBtKU2kknUQ@mail.gmail.com>
 <CAEcL5t4LOQZ+H7wfgEL3oSnX6EProzmss_2kL7+k9Hbd5y8oSQ@mail.gmail.com>
 <CAEcL5t6YomxS1ugVkyQ0L5X=uQFAqC9uK1pJwWCZqRutRHgnjA@mail.gmail.com>
 <CAE-7VJkxUyiVwpC6=5JdfGEwxtpvFEfLwBxadCJSZrET3tc_RA@mail.gmail.com>
 <CAE-7VJnzPH1D5X-xJQ+jHK1UjFG49Yb_-iuk2j0+fUTnEJGGZA@mail.gmail.com>
 <CAF2skS7pSPKqriq+rfsPTf=S+7+vuqXPuLB-O4AfAa1ZR38_Mw@mail.gmail.com>
 <CAE-7VJ=Jy5Y8iNiFxkO_2Rx2ZuoJMKSdCw5ZsUi63_ouHm7j_Q@mail.gmail.com>
 <CAKME8fHJ-0jCymCqyi=UYv2_HnQc2exUzg5p+RDEyfx=KTz4Zg@mail.gmail.com>
 <CAE-7VJngFnxZ7ia6Y3kqLKyZ1-T2DOVnc74eJXkZ+_3tw_71tw@mail.gmail.com>
 <CAE-7VJmB6wERryTW0SdkHD2LN_F_tHu2KgBFh5i8=3oCooG3+g@mail.gmail.com>
 <CAKME8fFrT0i3f-Mfq9q0Q2+TPE-suP7bd4X+HFECOyumJjNY=g@mail.gmail.com>
 <CAE-7VJnKXwjWCTHS3_-L_bezwTEUx24jHUyix8Ci7NkQrO5bWg@mail.gmail.com>
 <CANXz0SZC=Afg+sQggPsBcn9+BLbCQJ1+y0Cd2jJk1fUPW0iQxw@mail.gmail.com>
 <CAE-7VJkapY_mB6NFF5an6CpVLEZpvKpkopsgkmNXJ4SvpS+g+A@mail.gmail.com>
 <CANXz0SYXX-nrmq6jrRhJQ0jkosRTjvOh6_GyYkMaNQZKAWY33g@mail.gmail.com>
 <CAE-7VJmsL7DtLY=jXonCqxikxpU9045BS+P0zsQzAdzDbFCnSA@mail.gmail.com>
 <CANXz0SYOwoTtVHaoLkENLfoxw2jvUvTu=sMLV-EOuwJ2yXkC6w@mail.gmail.com>
 <CAE-7VJ==Ma59naju3Jc-Ymjqfmgv9TBzwxM9ivbgGQ9ujqcRYw@mail.gmail.com>
 <CANXz0SaYdfSaksP-dLdb0n2C1RD3X2Ti3uiQNMXcw30pFCOiCw@mail.gmail.com>
 <CAE-7VJkSvPT2-tQvdQiCzS80PvUtzn9kFP7OzaX6gG5voBKOkg@mail.gmail.com>
Message-ID: <CAE-7VJk+uiSbKXZhAgKb=o5=NaEu4AXWT9Pa+HdqSw3+-7J0sw@mail.gmail.com>

2017-06-01 10:41 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> 2017-05-31 21:06 GMT+02:00 Ken Martin <ken.martin at kitware.com>:
>> Are you setting window->SetMultisamples(0) as well early on?
>
> I've now tried with window->SetMultisamples(0) as soon as the window
> is constructed (updated test case below). Volumes are still not
> showing up when running with QVTKOpenGLWidget, while with plain VTK
> window it does :/
>
> This is with Qt 5.6 branch patched as you suggested.
>
> I think I'm running out of options :(
>
> I've looked through reported PV issues (since the problem manifests
> also there on this machine), and I believe this it:
>
>     https://gitlab.kitware.com/paraview/paraview/issues/17461
>
> That bug mentions Windows 10 explicitly, while I'm seeing it on
> Windows 7, but I think that's just coincidental. And David Cole
> reported being able to reproduce on Windows 8.1 / HD 4000.
>
> I've looked through all VTK bugs and cannot find it reported. Do you
> guys think it's time I report it?

I went ahead and filed https://gitlab.kitware.com/vtk/vtk/issues/17058

Let's continue discussion there.

Elvis

>
> Aron Heiser could not reproduce, but he was on HD 530, a much newer
> (Skylake) chip and with a newer driver version (20-something), than
> the reported cases. So probably this only occurs on certain Intel
> driver versions / chips.
>
> I think the Qt bad logic (QTBUG-60742) is a red herring in this case,
> since I'm now running with a version that will always honor the exact
> requested version.
>
> Elvis
>
>
> main.cpp:
>
> #include <algorithm>
>
> #include <vtkColorTransferFunction.h>
> #include <vtkGenericOpenGLRenderWindow.h>
> #include <vtkGPUVolumeRayCastMapper.h>
> #include <vtkImageData.h>
> #include <vtkNew.h>
> #include <vtkPiecewiseFunction.h>
> #include <vtkProperty.h>
> #include <vtkRenderer.h>
> #include <vtkRenderWindow.h>
> #include <vtkRenderWindowInteractor.h>
> #include <vtkVolume.h>
> #include <vtkVolumeProperty.h>
>
> #include <QVTKOpenGLWidget.h>
>
> #include <QApplication>
>
> int main(int argc, char *argv[])
> {
>     auto defaultFormat = QVTKOpenGLWidget::defaultFormat();
>     defaultFormat.setSamples(0);
>     QSurfaceFormat::setDefaultFormat(defaultFormat);
>
>     QApplication app(argc, argv);
>
>     // Set up volume rendering
>     vtkNew<vtkColorTransferFunction> colorFunction;
>     colorFunction->AddRGBPoint(0.0, 0.0, 0.0, 0.0);
>     colorFunction->AddRGBPoint(1.0, 0.0, 0.0, 0.0);
>
>     vtkNew<vtkPiecewiseFunction> opacityFunction;
>     opacityFunction->AddPoint(0.0, 0.0);
>     opacityFunction->AddPoint(1.0, 1.0);
>
>     vtkNew<vtkImageData> imageData;
>     imageData->SetExtent(0, 200, 0, 200, 0, 200);
>     imageData->AllocateScalars(VTK_FLOAT, 1);
>     std::fill_n(static_cast<float *>(imageData->GetScalarPointer()),
> 8000000, 0.01);
>
>     vtkNew<vtkGPUVolumeRayCastMapper> volumeMapper;
>     volumeMapper->SetInputData(imageData.Get());
>
>     vtkNew<vtkVolumeProperty> volumeProperty;
>     volumeProperty->SetScalarOpacity(opacityFunction.Get());
>     volumeProperty->SetColor(colorFunction.Get());
>     volumeProperty->ShadeOff();
>
>     vtkNew<vtkVolume> volume;
>     volume->SetMapper(volumeMapper.Get());
>     volume->SetProperty(volumeProperty.Get());
>
>     vtkNew<vtkRenderer> renderer;
>     renderer->AddVolume(volume.Get());
>     renderer->SetBackground(1.0, 1.0, 1.0);
>
>     if (argc > 1) {
>         // Render with QVTKOpenGLWidget
>         vtkNew<vtkGenericOpenGLRenderWindow> window;
>     window->SetMultiSamples(0);
>         window->AddRenderer(renderer.Get());
>
>         auto widget = new QVTKOpenGLWidget();
>         widget->SetRenderWindow(window.Get());
>         widget->show();
>
>         return app.exec();
>     } else {
>         // Render with "plain" render window / interactor
>         vtkNew<vtkRenderWindow> window;
>     window->SetMultiSamples(0);
>         window->AddRenderer(renderer.Get());
>
>         vtkNew<vtkRenderWindowInteractor> interactor;
>         interactor->SetRenderWindow(window.Get());
>         interactor->Start();
>
>         return 0;
>     }
> }
>
>
> CMakeLists.txt:
>
> cmake_minimum_required(VERSION 3.1)
>
> project(TestCase)
>
> find_package(VTK 8.0 COMPONENTS
>     vtkCommonCore
>     vtkCommonDataModel
>     vtkCommonExecutionModel
>     vtkCommonMath
>     vtkFiltersSources
>     vtkGUISupportQt
>     vtkInteractionStyle
>     vtkRenderingCore
>     vtkRenderingOpenGL2
>     vtkRenderingVolume
>     vtkRenderingVolumeOpenGL2
>     REQUIRED
> )
>
> find_package(Qt5Widgets REQUIRED)
>
> add_executable(TestCase main.cpp)
>
> target_link_libraries(TestCase PUBLIC
>     vtkCommonCore
>     vtkCommonDataModel
>     vtkCommonExecutionModel
>     vtkCommonMath
>     vtkFiltersSources
>     vtkGUISupportQt
>     vtkInteractionStyle
>     vtkRenderingCore
>     vtkRenderingOpenGL2
>     vtkRenderingVolume
>     vtkRenderingVolumeOpenGL2
>     Qt5::Widgets
> )
>
> target_include_directories(TestCase PUBLIC
>     ${VTK_INCLUDE_DIRS}
> )
>
> target_compile_definitions(TestCase PUBLIC
>     ${VTK_DEFINITIONS}
> )
>
> set_target_properties(TestCase PROPERTIES
>     CXX_STANDARD 14
>     CXX_STANDARD_REQUIRED ON
> )
>
>>
>> On Wed, May 31, 2017 at 2:55 PM, Elvis Stansvik
>> <elvis.stansvik at orexplore.com> wrote:
>>>
>>> 2017-05-31 18:53 GMT+02:00 Ken Martin <ken.martin at kitware.com>:
>>> > If it is only VolumeRendering then it may be you are requesting
>>> > Multisamples. What happens if you turn that off?
>>>
>>> Multisamples is turned off (see my test case in my initial mail):
>>>
>>>     auto defaultFormat = QVTKOpenGLWidget::defaultFormat();
>>>     defaultFormat.setSamples(0);
>>>     QSurfaceFormat::setDefaultFormat(defaultFormat);
>>>
>>> It would be great if you could try the test case out on the 4600
>>> system where you said you had problems with PV 5.4. I think it would
>>> help in narrowing down the issue.
>>>
>>> Make sure you run it with a parameter (e.g. "TestCase 1"), so that it
>>> uses QVTKOpenGLWidget and not a plain render window/interactor.
>>>
>>> Elvis
>>>
>>> >
>>> > On Wed, May 31, 2017 at 11:27 AM, Elvis Stansvik
>>> > <elvis.stansvik at orexplore.com> wrote:
>>> >>
>>> >> 2017-05-26 14:35 GMT+02:00 Ken Martin <ken.martin at kitware.com>:
>>> >> > If you have a build of QT I think you could change
>>> >> >
>>> >> >
>>> >> >
>>> >> > https://github.com/qt/qtbase/blob/dev/src/plugins/platforms/windows/qwindowsglcontext.cpp#L730
>>> >> >
>>> >> > const int requestedVersion = qMin((format.majorVersion() << 8) +
>>> >> > format.minorVersion(),
>>> >> > staticContext.defaultFormat.version);
>>> >> >
>>> >> > to be
>>> >> >
>>> >> > const int requestedVersion = (format.majorVersion() << 8) +
>>> >> > format.minorVersion());
>>> >> >
>>> >> > and it would fix it for VTK/ParaView. Not sure if it has any other
>>> >> > consequences for Qt or if it would hit some different issue though.
>>> >> > Qt
>>> >> > on
>>> >> > windows does some tricky stuff to support OpenGL/Angle/ES2.
>>> >>
>>> >> I patched Qt (5.6 branch) like this and tried again, but no luck :(
>>> >> Volumes still not showing up..
>>> >>
>>> >> ..and thinking about it, could this really have been the problem I was
>>> >> seeing? If Qt wrongly gave back a lower-versioned context (because of
>>> >> it's questionable logic), as described in the Qt bug report, then
>>> >> wouldn't VTK error out from the failure to obtain the version it
>>> >> requested? In my case, there's no output/error at all from VTK. It's
>>> >> just that the volumes won't show up.
>>> >>
>>> >> Another render window where I just have a vtkChartXY does show up
>>> >> fine. It's only the volume rendering that isn't working.
>>> >>
>>> >> Would be interesting if others who could reproduce could try patching
>>> >> their Qt like this to see if it solves it.
>>> >>
>>> >> Elvis
>>> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Fri, May 26, 2017 at 4:32 AM, Elvis Stansvik
>>> >> > <elvis.stansvik at orexplore.com> wrote:
>>> >> >>
>>> >> >> 2017-05-26 2:24 GMT+02:00 Ken Martin <ken.martin at kitware.com>:
>>> >> >> > I can reproduce this issue with PV 5.4 on my 4600 system. 99% sure
>>> >> >> > it
>>> >> >> > is
>>> >> >> > a
>>> >> >> > Qt bug we already bumped into with Mesa. They have what looks to
>>> >> >> > me
>>> >> >> > like
>>> >> >> > some odd bad logic on windows for creating a context where they
>>> >> >> > will
>>> >> >> > not
>>> >> >> > give you a core context later than the latest compatibility
>>> >> >> > context
>>> >> >> > they
>>> >> >> > can
>>> >> >> > get. For some vendors that is fine but for others they only offer
>>> >> >> > Comp
>>> >> >> > contexts up to 2.1 or 3.0 but not 3.2. So while the driver may
>>> >> >> > support
>>> >> >> > OpenGL 4 in Core mode, Qt restricts you to 3.0.  I suspect if they
>>> >> >> > fixed
>>> >> >> > that the issue would go away. I believe Ben filed a bug report
>>> >> >> > with
>>> >> >> > them
>>> >> >> > (Qt) when he bumped into this when using Mesa on Windows.
>>> >> >>
>>> >> >> Ah yes, that could definitely be it. I found Ben's bug:
>>> >> >>
>>> >> >>     https://bugreports.qt.io/browse/QTBUG-60742
>>> >> >>
>>> >> >> The affected version is listed as 5.8.0, but I'm having trouble on
>>> >> >> 5.6.2, so I guess the bad logic is there as well.
>>> >> >>
>>> >> >> So let's hope for a fix in Qt then. But in the meantime, is there
>>> >> >> anything you can think if that I could do to work around it? I
>>> >> >> really
>>> >> >> want our application to work on these kinds of machines (the one I
>>> >> >> have was picked as a sort of a baseline for us wrt to requirements).
>>> >> >>
>>> >> >> In the bug report Ben mentions hacking around it with
>>> >> >> MESA_GL_VERSION_OVERRIDE, but that obviously doesn't apply when not
>>> >> >> using Mesa.
>>> >> >>
>>> >> >> Elvis
>>> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >> > On Thu, May 25, 2017 at 7:44 PM, Elvis Stansvik
>>> >> >> > <elvis.stansvik at orexplore.com> wrote:
>>> >> >> >>
>>> >> >> >> 2017-05-25 23:37 GMT+02:00 David Cole <DLRdave at aol.com>:
>>> >> >> >> > Yes, I ran it both ways.
>>> >> >> >> >
>>> >> >> >> > It works when run without the argument in the plain VTK render
>>> >> >> >> > window,
>>> >> >> >> > and it is broken (shows nothing) when run with an argument.
>>> >> >> >>
>>> >> >> >> Alright, that's good. Then we're seeing the same thing.
>>> >> >> >>
>>> >> >> >> > Seems like it's definitely related to older Intel drivers on
>>> >> >> >> > Windows.
>>> >> >> >>
>>> >> >> >> Yes, probably.
>>> >> >> >>
>>> >> >> >> > Not sure if there is an updated driver available for my
>>> >> >> >> > machine.
>>> >> >> >> > Hesitant to try changing/updating it for other reasons, and
>>> >> >> >> > sorry,
>>> >> >> >> > can't sacrifice this machine's current state for the purpose of
>>> >> >> >> > testing this out...
>>> >> >> >>
>>> >> >> >> No worries, I'm free to do as I please with the one I have, so
>>> >> >> >> I'll
>>> >> >> >> do
>>> >> >> >> some experimenting with different drivers when I'm back on
>>> >> >> >> Monday.
>>> >> >> >>
>>> >> >> >> Thanks to everyone trying this out.
>>> >> >> >>
>>> >> >> >> Elvis
>>> >> >> >>
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > D
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Thu, May 25, 2017 at 5:11 PM, Elvis Stansvik
>>> >> >> >> > <elvis.stansvik at orexplore.com> wrote:
>>> >> >> >> >> 2017-05-25 20:35 GMT+02:00 Elvis Stansvik
>>> >> >> >> >> <elvis.stansvik at orexplore.com>:
>>> >> >> >> >>> 2017-05-25 18:14 GMT+02:00 David Cole <DLRdave at aol.com>:
>>> >> >> >> >>>> Fails for me, too, on a 3.5 year old Dell XPS laptop,
>>> >> >> >> >>>> Windows
>>> >> >> >> >>>> 8.1,
>>> >> >> >> >>>> with an Intel HD Graphics 4000 running driver version
>>> >> >> >> >>>> 10.18.10.3316.
>>> >> >> >> >>>> I
>>> >> >> >> >>>> get your TestCase app window with nothing but an empty
>>> >> >> >> >>>> (white)
>>> >> >> >> >>>> client
>>> >> >> >> >>>> region.
>>> >> >> >> >>>>
>>> >> >> >> >>>> An app we have built against VTK 6.2-ish with the old OpenGL
>>> >> >> >> >>>> using
>>> >> >> >> >>>> VolumeSmartMapper works fine on this very same machine.
>>> >> >> >> >>>>
>>> >> >> >> >>>> Another data point...
>>> >> >> >> >>
>>> >> >> >> >> Just one more thing David, did you try also running the
>>> >> >> >> >> example
>>> >> >> >> >> without any argument on this machine? (That would make it use
>>> >> >> >> >> a
>>> >> >> >> >> regular vtkRenderWindow/vtkRenderWindowInteractor). It would
>>> >> >> >> >> be
>>> >> >> >> >> interesting to know if the volume shows up then. That would
>>> >> >> >> >> confirm
>>> >> >> >> >> that the machine can show volumes using VTK 8+OpenGL2 backend,
>>> >> >> >> >> just
>>> >> >> >> >> not with QVTKOpenGLWidget, so would strengthen my theory that
>>> >> >> >> >> it
>>> >> >> >> >> has
>>> >> >> >> >> something to do with the new QVTKOpenGLWidget.
>>> >> >> >> >>
>>> >> >> >> >> Elvis
>>> >> >> >> >>
>>> >> >> >> >>>
>>> >> >> >> >>> Finally a reproduction, I was beginning to despair :) Thanks
>>> >> >> >> >>> a
>>> >> >> >> >>> lot
>>> >> >> >> >>> David.
>>> >> >> >> >>>
>>> >> >> >> >>> And just to make sure, Aron, did you run the test case as
>>> >> >> >> >>> "TestCase
>>> >> >> >> >>> 1", with a parameter? That's the crucial thing, as otherwise
>>> >> >> >> >>> it'll
>>> >> >> >> >>> just use a regular vtkRenderWindow/vtkRenderWindowInteractor
>>> >> >> >> >>> (not
>>> >> >> >> >>> QVTKOpenGLWidget), and not exhibit the problem.
>>> >> >> >> >>>
>>> >> >> >> >>> Elvis
>>> >> >> >> >>>
>>> >> >> >> >>>>
>>> >> >> >> >>>>
>>> >> >> >> >>>> D
>>> >> >> >> >>>>
>>> >> >> >> >>>>
>>> >> >> >> >>>>
>>> >> >> >> >>>>
>>> >> >> >> >>>> On Thu, May 25, 2017 at 11:02 AM, Elvis Stansvik
>>> >> >> >> >>>> <elvis.stansvik at orexplore.com> wrote:
>>> >> >> >> >>>>> 2017-05-25 16:22 GMT+02:00 Aron Helser
>>> >> >> >> >>>>> <aron.helser at kitware.com>:
>>> >> >> >> >>>>>> Hi Elvis,
>>> >> >> >> >>>>>> I've got a Win10 laptop (dell precision 5510), with an
>>> >> >> >> >>>>>> Optimus
>>> >> >> >> >>>>>> setup - both
>>> >> >> >> >>>>>> intel and nvidia graphics.
>>> >> >> >> >>>>>> With your test case, I'm able to see the volume running
>>> >> >> >> >>>>>> either
>>> >> >> >> >>>>>> with
>>> >> >> >> >>>>>> Intel or
>>> >> >> >> >>>>>> nVidia, so it doesn't repro for me.
>>> >> >> >> >>>>>> I've got Intel HD530 graphics, with driver version
>>> >> >> >> >>>>>> 21.20.16.4627
>>> >> >> >> >>>>>> Sorry,
>>> >> >> >> >>>>>> Aron
>>> >> >> >> >>>>>
>>> >> >> >> >>>>> Alright, bugger. Thanks for testing though!
>>> >> >> >> >>>>>
>>> >> >> >> >>>>> I won't be at the office until Monday again, but when I'm
>>> >> >> >> >>>>> back
>>> >> >> >> >>>>> I'll
>>> >> >> >> >>>>> try experimenting with different driver versions.
>>> >> >> >> >>>>>
>>> >> >> >> >>>>> Elvis
>>> >> >> >> >>>>>
>>> >> >> >> >>>>>>
>>> >> >> >> >>>>>> On Wed, May 24, 2017 at 5:02 PM, Elvis Stansvik
>>> >> >> >> >>>>>> <elvis.stansvik at orexplore.com> wrote:
>>> >> >> >> >>>>>>>
>>> >> >> >> >>>>>>> 2017-05-24 22:49 GMT+02:00 Elvis Stansvik
>>> >> >> >> >>>>>>> <elvis.stansvik at orexplore.com>:
>>> >> >> >> >>>>>>> > 2017-05-24 22:20 GMT+02:00 Sankhesh Jhaveri
>>> >> >> >> >>>>>>> > <sankhesh.jhaveri at kitware.com>:
>>> >> >> >> >>>>>>> >> Hi Elvis,
>>> >> >> >> >>>>>>> >>
>>> >> >> >> >>>>>>> >> Unfortunately, I wasn?t able to reproduce this issue.
>>> >> >> >> >>>>>>> >> :(
>>> >> >> >> >>>>>>> >>
>>> >> >> >> >>>>>>> >> I don?t have a Windows machine with an Intel graphics
>>> >> >> >> >>>>>>> >> card
>>> >> >> >> >>>>>>> >> but
>>> >> >> >> >>>>>>> >> tried
>>> >> >> >> >>>>>>> >> ParaView on a couple of se Windows machines as well as
>>> >> >> >> >>>>>>> >> a
>>> >> >> >> >>>>>>> >> Mac
>>> >> >> >> >>>>>>> >> (with an
>>> >> >> >> >>>>>>> >> Intel
>>> >> >> >> >>>>>>> >> HD5600). Worked fine.
>>> >> >> >> >>>>>>> >
>>> >> >> >> >>>>>>> > Alright. Call for help then: Anyone else have a Windows
>>> >> >> >> >>>>>>> > 7
>>> >> >> >> >>>>>>> > machine with
>>> >> >> >> >>>>>>> > Intel graphics? Would be great if someone could
>>> >> >> >> >>>>>>> > reproduce.
>>> >> >> >> >>>>>>>
>>> >> >> >> >>>>>>> Forgot to say: Thanks a lot for trying to reproduce
>>> >> >> >> >>>>>>> Sankhesh.
>>> >> >> >> >>>>>>>
>>> >> >> >> >>>>>>> I've now put up the compiled self-contained test case
>>> >> >> >> >>>>>>> here:
>>> >> >> >> >>>>>>>
>>> >> >> >> >>>>>>>     http://dose.se/~estan/voltestcase-inst.zip (18 MB)
>>> >> >> >> >>>>>>>
>>> >> >> >> >>>>>>> If anyone with Windows (preferably Windows 7 if possible)
>>> >> >> >> >>>>>>> +
>>> >> >> >> >>>>>>> Intel
>>> >> >> >> >>>>>>> graphics could try running this test case with "TestCase
>>> >> >> >> >>>>>>> 1"
>>> >> >> >> >>>>>>> and
>>> >> >> >> >>>>>>> see if
>>> >> >> >> >>>>>>> the volume shows up, that would be great.
>>> >> >> >> >>>>>>>
>>> >> >> >> >>>>>>> (Running the test case with argc > 2 will make it use
>>> >> >> >> >>>>>>> QVTKOpenGLWidget, and is where I'm having trouble).
>>> >> >> >> >>>>>>>
>>> >> >> >> >>>>>>> Elvis
>>> >> >> >> >>>>>>>
>>> >> >> >> >>>>>>> >
>>> >> >> >> >>>>>>> > I could put up my build of the test case as a
>>> >> >> >> >>>>>>> > self-contained
>>> >> >> >> >>>>>>> > .zip, to
>>> >> >> >> >>>>>>> > make it easy to test.
>>> >> >> >> >>>>>>> >
>>> >> >> >> >>>>>>> >>
>>> >> >> >> >>>>>>> >> At this point, I am inclined to think that the
>>> >> >> >> >>>>>>> >> graphics
>>> >> >> >> >>>>>>> >> drivers
>>> >> >> >> >>>>>>> >> on your
>>> >> >> >> >>>>>>> >> Windows machine may need updating.
>>> >> >> >> >>>>>>> >
>>> >> >> >> >>>>>>> > Hm, but it works fine if I don't use QVTKOpenGLWidget,
>>> >> >> >> >>>>>>> > and
>>> >> >> >> >>>>>>> > just
>>> >> >> >> >>>>>>> > use a
>>> >> >> >> >>>>>>> > plain vtkRenderWindow + vtkRenderWindowInteractor.
>>> >> >> >> >>>>>>> > Wouldn't
>>> >> >> >> >>>>>>> > that
>>> >> >> >> >>>>>>> > suggest that the drivers are capable enough, and that
>>> >> >> >> >>>>>>> > the
>>> >> >> >> >>>>>>> > problem is
>>> >> >> >> >>>>>>> > somehow in QVTKOpenGLWidget (or QOpenGLWidget)?
>>> >> >> >> >>>>>>> >
>>> >> >> >> >>>>>>> > Elvis
>>> >> >> >> >>>>>>> >
>>> >> >> >> >>>>>>> >>
>>> >> >> >> >>>>>>> >>
>>> >> >> >> >>>>>>> >> On Wed, May 24, 2017 at 12:16 PM Sankhesh Jhaveri
>>> >> >> >> >>>>>>> >> <sankhesh.jhaveri at kitware.com> wrote:
>>> >> >> >> >>>>>>> >>>
>>> >> >> >> >>>>>>> >>> Okay thanks.
>>> >> >> >> >>>>>>> >>>
>>> >> >> >> >>>>>>> >>> I?ll take a look.
>>> >> >> >> >>>>>>> >>>
>>> >> >> >> >>>>>>> >>>
>>> >> >> >> >>>>>>> >>> On Wed, May 24, 2017 at 8:18 AM Elvis Stansvik
>>> >> >> >> >>>>>>> >>> <elvis.stansvik at orexplore.com> wrote:
>>> >> >> >> >>>>>>> >>>>
>>> >> >> >> >>>>>>> >>>> 2017-05-23 15:41 GMT+02:00 Sankhesh Jhaveri
>>> >> >> >> >>>>>>> >>>> <sankhesh.jhaveri at kitware.com>:
>>> >> >> >> >>>>>>> >>>> > Hi Elvis,
>>> >> >> >> >>>>>>> >>>> >
>>> >> >> >> >>>>>>> >>>> > Could you try downloading the ParaView nightly
>>> >> >> >> >>>>>>> >>>> > binary
>>> >> >> >> >>>>>>> >>>> > and
>>> >> >> >> >>>>>>> >>>> > test
>>> >> >> >> >>>>>>> >>>> > volume
>>> >> >> >> >>>>>>> >>>> > rendering there? You can use the wavelet source
>>> >> >> >> >>>>>>> >>>> > for a
>>> >> >> >> >>>>>>> >>>> > test
>>> >> >> >> >>>>>>> >>>> > dataset.
>>> >> >> >> >>>>>>> >>>> > ParaView
>>> >> >> >> >>>>>>> >>>> > uses the QVTKOpenGLWidget and it would be a good
>>> >> >> >> >>>>>>> >>>> > test
>>> >> >> >> >>>>>>> >>>> > before diving
>>> >> >> >> >>>>>>> >>>> > into the
>>> >> >> >> >>>>>>> >>>> > code.
>>> >> >> >> >>>>>>> >>>>
>>> >> >> >> >>>>>>> >>>> I tried the wavelet example with Paraview
>>> >> >> >> >>>>>>> >>>> 5.4.0-RC1-125-g435b603
>>> >> >> >> >>>>>>> >>>> 64-bit, and the problem is the same as in my minimal
>>> >> >> >> >>>>>>> >>>> test
>>> >> >> >> >>>>>>> >>>> case. The
>>> >> >> >> >>>>>>> >>>> volume won't show up.
>>> >> >> >> >>>>>>> >>>>
>>> >> >> >> >>>>>>> >>>> It does show up if I switch to the software based
>>> >> >> >> >>>>>>> >>>> ray
>>> >> >> >> >>>>>>> >>>> cast
>>> >> >> >> >>>>>>> >>>> mapper
>>> >> >> >> >>>>>>> >>>> (but
>>> >> >> >> >>>>>>> >>>> not with GPU or smart, which I guess both result in
>>> >> >> >> >>>>>>> >>>> the
>>> >> >> >> >>>>>>> >>>> GPU
>>> >> >> >> >>>>>>> >>>> one being
>>> >> >> >> >>>>>>> >>>> used).
>>> >> >> >> >>>>>>> >>>>
>>> >> >> >> >>>>>>> >>>> Please tell me if there's anything else I can do to
>>> >> >> >> >>>>>>> >>>> help
>>> >> >> >> >>>>>>> >>>> debugging.
>>> >> >> >> >>>>>>> >>>> There are no errors printed when I run my test case.
>>> >> >> >> >>>>>>> >>>>
>>> >> >> >> >>>>>>> >>>> Elvis
>>> >> >> >> >>>>>>> >>>>
>>> >> >> >> >>>>>>> >>>> >
>>> >> >> >> >>>>>>> >>>> > Thanks,
>>> >> >> >> >>>>>>> >>>> > Sankhesh
>>> >> >> >> >>>>>>> >>>> >
>>> >> >> >> >>>>>>> >>>> >
>>> >> >> >> >>>>>>> >>>> > On Tue, May 23, 2017 at 6:50 AM Elvis Stansvik
>>> >> >> >> >>>>>>> >>>> > <elvis.stansvik at orexplore.com> wrote:
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> Hi all,
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> In porting to QVTKOpenGLWidget, I can't get
>>> >> >> >> >>>>>>> >>>> >> volumes
>>> >> >> >> >>>>>>> >>>> >> rendered using
>>> >> >> >> >>>>>>> >>>> >> vtkGPUVolumeRayCastMapper to show up on Windows
>>> >> >> >> >>>>>>> >>>> >> 7,
>>> >> >> >> >>>>>>> >>>> >> Intel
>>> >> >> >> >>>>>>> >>>> >> graphics
>>> >> >> >> >>>>>>> >>>> >> (HD
>>> >> >> >> >>>>>>> >>>> >> 4600). They show up fine on Linux. They also show
>>> >> >> >> >>>>>>> >>>> >> up
>>> >> >> >> >>>>>>> >>>> >> fine
>>> >> >> >> >>>>>>> >>>> >> on
>>> >> >> >> >>>>>>> >>>> >> Windows 7
>>> >> >> >> >>>>>>> >>>> >> if using a plain VTK render window. I've tried
>>> >> >> >> >>>>>>> >>>> >> turning
>>> >> >> >> >>>>>>> >>>> >> off
>>> >> >> >> >>>>>>> >>>> >> multisampling with setSamples(0) on the default
>>> >> >> >> >>>>>>> >>>> >> QSurfaceFormat.
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> The below test case illustrates the issue. See
>>> >> >> >> >>>>>>> >>>> >> the
>>> >> >> >> >>>>>>> >>>> >> attached
>>> >> >> >> >>>>>>> >>>> >> screenshots from running "TestCase" (left) and
>>> >> >> >> >>>>>>> >>>> >> "TestCase
>>> >> >> >> >>>>>>> >>>> >> 1"
>>> >> >> >> >>>>>>> >>>> >> (right).
>>> >> >> >> >>>>>>> >>>> >> The former uses a plain render window while the
>>> >> >> >> >>>>>>> >>>> >> latter
>>> >> >> >> >>>>>>> >>>> >> uses the
>>> >> >> >> >>>>>>> >>>> >> new
>>> >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget. Notice how in the Windows 7
>>> >> >> >> >>>>>>> >>>> >> screenshot,
>>> >> >> >> >>>>>>> >>>> >> the
>>> >> >> >> >>>>>>> >>>> >> plain
>>> >> >> >> >>>>>>> >>>> >> VTK rendering works fine, but the
>>> >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget
>>> >> >> >> >>>>>>> >>>> >> one
>>> >> >> >> >>>>>>> >>>> >> is
>>> >> >> >> >>>>>>> >>>> >> not
>>> >> >> >> >>>>>>> >>>> >> showing
>>> >> >> >> >>>>>>> >>>> >> the volume.
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> Versions used:
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> Kubuntu Linux 16.04
>>> >> >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2
>>> >> >> >> >>>>>>> >>>> >> Qt 5.5.1
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> Windows 7
>>> >> >> >> >>>>>>> >>>> >> VTK 8.0.0.rc1, OpenGL2
>>> >> >> >> >>>>>>> >>>> >> Qt 5.6.2
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> Any ideas what the problem might be?
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> I can provide a standalone .zip distribution of
>>> >> >> >> >>>>>>> >>>> >> my
>>> >> >> >> >>>>>>> >>>> >> build
>>> >> >> >> >>>>>>> >>>> >> of the
>>> >> >> >> >>>>>>> >>>> >> test
>>> >> >> >> >>>>>>> >>>> >> case if you want.
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> Note that this issue is orthogonal to the alpha
>>> >> >> >> >>>>>>> >>>> >> issue I
>>> >> >> >> >>>>>>> >>>> >> reported
>>> >> >> >> >>>>>>> >>>> >> and
>>> >> >> >> >>>>>>> >>>> >> got solved in my other thread.
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> Many thanks in advance,
>>> >> >> >> >>>>>>> >>>> >> Elvis
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> main.cpp:
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> #include <algorithm>
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkColorTransferFunction.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkGenericOpenGLRenderWindow.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkGPUVolumeRayCastMapper.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkImageData.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkNew.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkPiecewiseFunction.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkProperty.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkRenderer.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkRenderWindow.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkRenderWindowInteractor.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkVolume.h>
>>> >> >> >> >>>>>>> >>>> >> #include <vtkVolumeProperty.h>
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> #include <QVTKOpenGLWidget.h>
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> #include <QApplication>
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> int main(int argc, char *argv[])
>>> >> >> >> >>>>>>> >>>> >> {
>>> >> >> >> >>>>>>> >>>> >>     auto defaultFormat =
>>> >> >> >> >>>>>>> >>>> >> QVTKOpenGLWidget::defaultFormat();
>>> >> >> >> >>>>>>> >>>> >>     defaultFormat.setSamples(0);
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> QSurfaceFormat::setDefaultFormat(defaultFormat);
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>     QApplication app(argc, argv);
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>     // Set up volume rendering
>>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkColorTransferFunction>
>>> >> >> >> >>>>>>> >>>> >> colorFunction;
>>> >> >> >> >>>>>>> >>>> >>     colorFunction->AddRGBPoint(0.0, 0.0, 0.0,
>>> >> >> >> >>>>>>> >>>> >> 0.0);
>>> >> >> >> >>>>>>> >>>> >>     colorFunction->AddRGBPoint(1.0, 0.0, 0.0,
>>> >> >> >> >>>>>>> >>>> >> 0.0);
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkPiecewiseFunction> opacityFunction;
>>> >> >> >> >>>>>>> >>>> >>     opacityFunction->AddPoint(0.0, 0.0);
>>> >> >> >> >>>>>>> >>>> >>     opacityFunction->AddPoint(1.0, 1.0);
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkImageData> imageData;
>>> >> >> >> >>>>>>> >>>> >>     imageData->SetExtent(0, 200, 0, 200, 0, 200);
>>> >> >> >> >>>>>>> >>>> >>     imageData->AllocateScalars(VTK_FLOAT, 1);
>>> >> >> >> >>>>>>> >>>> >>     std::fill_n(static_cast<float
>>> >> >> >> >>>>>>> >>>> >> *>(imageData->GetScalarPointer()),
>>> >> >> >> >>>>>>> >>>> >> 8000000, 0.01);
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkGPUVolumeRayCastMapper>
>>> >> >> >> >>>>>>> >>>> >> volumeMapper;
>>> >> >> >> >>>>>>> >>>> >>     volumeMapper->SetInputData(imageData.Get());
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkVolumeProperty> volumeProperty;
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> volumeProperty->SetScalarOpacity(opacityFunction.Get());
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> volumeProperty->SetColor(colorFunction.Get());
>>> >> >> >> >>>>>>> >>>> >>     volumeProperty->ShadeOff();
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkVolume> volume;
>>> >> >> >> >>>>>>> >>>> >>     volume->SetMapper(volumeMapper.Get());
>>> >> >> >> >>>>>>> >>>> >>     volume->SetProperty(volumeProperty.Get());
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>     vtkNew<vtkRenderer> renderer;
>>> >> >> >> >>>>>>> >>>> >>     renderer->AddVolume(volume.Get());
>>> >> >> >> >>>>>>> >>>> >>     renderer->SetBackground(1.0, 1.0, 1.0);
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>     if (argc > 1) {
>>> >> >> >> >>>>>>> >>>> >>         // Render with QVTKOpenGLWidget
>>> >> >> >> >>>>>>> >>>> >>         vtkNew<vtkGenericOpenGLRenderWindow>
>>> >> >> >> >>>>>>> >>>> >> window;
>>> >> >> >> >>>>>>> >>>> >>         window->AddRenderer(renderer.Get());
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>         auto widget = new QVTKOpenGLWidget();
>>> >> >> >> >>>>>>> >>>> >>         widget->SetRenderWindow(window.Get());
>>> >> >> >> >>>>>>> >>>> >>         widget->show();
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>         return app.exec();
>>> >> >> >> >>>>>>> >>>> >>     } else {
>>> >> >> >> >>>>>>> >>>> >>         // Render with "plain" render window /
>>> >> >> >> >>>>>>> >>>> >> interactor
>>> >> >> >> >>>>>>> >>>> >>         vtkNew<vtkRenderWindow> window;
>>> >> >> >> >>>>>>> >>>> >>         window->AddRenderer(renderer.Get());
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>         vtkNew<vtkRenderWindowInteractor>
>>> >> >> >> >>>>>>> >>>> >> interactor;
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> interactor->SetRenderWindow(window.Get());
>>> >> >> >> >>>>>>> >>>> >>         interactor->Start();
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>         return 0;
>>> >> >> >> >>>>>>> >>>> >>     }
>>> >> >> >> >>>>>>> >>>> >> }
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> CMakeLists.txt:
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> cmake_minimum_required(VERSION 3.1)
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> project(TestCase)
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> find_package(VTK 8.0 COMPONENTS
>>> >> >> >> >>>>>>> >>>> >>     vtkCommonCore
>>> >> >> >> >>>>>>> >>>> >>     vtkCommonDataModel
>>> >> >> >> >>>>>>> >>>> >>     vtkCommonExecutionModel
>>> >> >> >> >>>>>>> >>>> >>     vtkCommonMath
>>> >> >> >> >>>>>>> >>>> >>     vtkFiltersSources
>>> >> >> >> >>>>>>> >>>> >>     vtkGUISupportQt
>>> >> >> >> >>>>>>> >>>> >>     vtkInteractionStyle
>>> >> >> >> >>>>>>> >>>> >>     vtkRenderingCore
>>> >> >> >> >>>>>>> >>>> >>     vtkRenderingOpenGL2
>>> >> >> >> >>>>>>> >>>> >>     vtkRenderingVolume
>>> >> >> >> >>>>>>> >>>> >>     vtkRenderingVolumeOpenGL2
>>> >> >> >> >>>>>>> >>>> >>     REQUIRED
>>> >> >> >> >>>>>>> >>>> >> )
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> find_package(Qt5Widgets REQUIRED)
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> add_executable(TestCase main.cpp)
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> target_link_libraries(TestCase PUBLIC
>>> >> >> >> >>>>>>> >>>> >>     vtkCommonCore
>>> >> >> >> >>>>>>> >>>> >>     vtkCommonDataModel
>>> >> >> >> >>>>>>> >>>> >>     vtkCommonExecutionModel
>>> >> >> >> >>>>>>> >>>> >>     vtkCommonMath
>>> >> >> >> >>>>>>> >>>> >>     vtkFiltersSources
>>> >> >> >> >>>>>>> >>>> >>     vtkGUISupportQt
>>> >> >> >> >>>>>>> >>>> >>     vtkInteractionStyle
>>> >> >> >> >>>>>>> >>>> >>     vtkRenderingCore
>>> >> >> >> >>>>>>> >>>> >>     vtkRenderingOpenGL2
>>> >> >> >> >>>>>>> >>>> >>     vtkRenderingVolume
>>> >> >> >> >>>>>>> >>>> >>     vtkRenderingVolumeOpenGL2
>>> >> >> >> >>>>>>> >>>> >>     Qt5::Widgets
>>> >> >> >> >>>>>>> >>>> >> )
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> target_include_directories(TestCase PUBLIC
>>> >> >> >> >>>>>>> >>>> >>     ${VTK_INCLUDE_DIRS}
>>> >> >> >> >>>>>>> >>>> >> )
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> target_compile_definitions(TestCase PUBLIC
>>> >> >> >> >>>>>>> >>>> >>     ${VTK_DEFINITIONS}
>>> >> >> >> >>>>>>> >>>> >> )
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> >> set_target_properties(TestCase PROPERTIES
>>> >> >> >> >>>>>>> >>>> >>     CXX_STANDARD 14
>>> >> >> >> >>>>>>> >>>> >>     CXX_STANDARD_REQUIRED ON
>>> >> >> >> >>>>>>> >>>> >> )
>>> >> >> >> >>>>>>> >>>> >> _______________________________________________
>>> >> >> >> >>>>>>> >>>> >> 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
>>> >> >> >> >>>>>>> >>>> >>
>>> >> >> >> >>>>>>> >>>> > --
>>> >> >> >> >>>>>>> >>>> >
>>> >> >> >> >>>>>>> >>>> > Sankhesh Jhaveri
>>> >> >> >> >>>>>>> >>>> >
>>> >> >> >> >>>>>>> >>>> > Sr. Research & Development Engineer | Kitware |
>>> >> >> >> >>>>>>> >>>> > (518)
>>> >> >> >> >>>>>>> >>>> > 881-4417
>>> >> >> >> >>>>>>> >>>
>>> >> >> >> >>>>>>> >>> --
>>> >> >> >> >>>>>>> >>>
>>> >> >> >> >>>>>>> >>> Sankhesh Jhaveri
>>> >> >> >> >>>>>>> >>>
>>> >> >> >> >>>>>>> >>> Sr. Research & Development Engineer | Kitware | (518)
>>> >> >> >> >>>>>>> >>> 881-4417
>>> >> >> >> >>>>>>> >>
>>> >> >> >> >>>>>>> >> --
>>> >> >> >> >>>>>>> >>
>>> >> >> >> >>>>>>> >> Sankhesh Jhaveri
>>> >> >> >> >>>>>>> >>
>>> >> >> >> >>>>>>> >> Sr. Research & Development Engineer | Kitware | (518)
>>> >> >> >> >>>>>>> >> 881-4417
>>> >> >> >> >>>>>>> _______________________________________________
>>> >> >> >> >>>>>>> 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
>>> >> >> >> >>>>>>>
>>> >> >> >> >>>>>>
>>> >> >> >> >>>>> _______________________________________________
>>> >> >> >> >>>>> 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
>>> >> >> >> >>>>>
>>> >> >> >> _______________________________________________
>>> >> >> >> 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
>>> >> >> >>
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > --
>>> >> >> > Ken Martin PhD
>>> >> >> > Distinguished Engineer
>>> >> >> > Kitware Inc.
>>> >> >> > 28 Corporate Drive
>>> >> >> > Clifton Park NY 12065
>>> >> >> >
>>> >> >> > This communication, including all attachments, contains
>>> >> >> > confidential
>>> >> >> > and
>>> >> >> > legally privileged information, and it is intended only for the
>>> >> >> > use
>>> >> >> > of
>>> >> >> > the
>>> >> >> > addressee.  Access to this email by anyone else is unauthorized.
>>> >> >> > If
>>> >> >> > you
>>> >> >> > are
>>> >> >> > not the intended recipient, any disclosure, copying, distribution
>>> >> >> > or
>>> >> >> > any
>>> >> >> > action taken in reliance on it is prohibited and may be unlawful.
>>> >> >> > If
>>> >> >> > you
>>> >> >> > received this communication in error please notify us immediately
>>> >> >> > and
>>> >> >> > destroy the original message.  Thank you.
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Ken Martin PhD
>>> >> > Distinguished Engineer
>>> >> > Kitware Inc.
>>> >> > 28 Corporate Drive
>>> >> > Clifton Park NY 12065
>>> >> >
>>> >> > This communication, including all attachments, contains confidential
>>> >> > and
>>> >> > legally privileged information, and it is intended only for the use
>>> >> > of
>>> >> > the
>>> >> > addressee.  Access to this email by anyone else is unauthorized. If
>>> >> > you
>>> >> > are
>>> >> > not the intended recipient, any disclosure, copying, distribution or
>>> >> > any
>>> >> > action taken in reliance on it is prohibited and may be unlawful. If
>>> >> > you
>>> >> > received this communication in error please notify us immediately and
>>> >> > destroy the original message.  Thank you.
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Ken Martin PhD
>>> > Distinguished Engineer
>>> > Kitware Inc.
>>> > 28 Corporate Drive
>>> > Clifton Park NY 12065
>>> >
>>> > This communication, including all attachments, contains confidential and
>>> > legally privileged information, and it is intended only for the use of
>>> > the
>>> > addressee.  Access to this email by anyone else is unauthorized. If you
>>> > are
>>> > not the intended recipient, any disclosure, copying, distribution or any
>>> > action taken in reliance on it is prohibited and may be unlawful. If you
>>> > received this communication in error please notify us immediately and
>>> > destroy the original message.  Thank you.
>>
>>
>>
>>
>> --
>> Ken Martin PhD
>> Distinguished Engineer
>> Kitware Inc.
>> 28 Corporate Drive
>> Clifton Park NY 12065
>>
>> This communication, including all attachments, contains confidential and
>> legally privileged information, and it is intended only for the use of the
>> addressee.  Access to this email by anyone else is unauthorized. If you are
>> not the intended recipient, any disclosure, copying, distribution or any
>> action taken in reliance on it is prohibited and may be unlawful. If you
>> received this communication in error please notify us immediately and
>> destroy the original message.  Thank you.

From bill.lorensen at gmail.com  Thu Jun  1 11:10:54 2017
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 1 Jun 2017 11:10:54 -0400
Subject: [vtk-developers] ANN: VTKWikiExamples are now VTKExamples
Message-ID: <CADZJ4hNVHcdi3Wj=yMGcqNfk+c=oFcxueev7k+Bw=kBG6mkEKg@mail.gmail.com>

Folks,

We are moving the wiki-based VTK examples: http://www.vtk.org/Wiki/VTK/Examples
to a git-based repository:  https://lorensen.github.io/VTKExamples/

The new VTK Examples have a more modern look and feel and perform well
on mobile devices. The pages use Google's Material Design guidelines
so navigation will look familiar to many users.

All of the wiki examples have been moved to the new repository.
Eventually we will decommission the old wiki-based examples.

Consider this a beta announcement. We need feedback and help to fix
the description pages.

To contribute, please see these instructions:
https://lorensen.github.io/VTKExamples/site/Instructions/ForDevelopers/

To use the new examples, see the instructions here:
https://lorensen.github.io/VTKExamples/site/Instructions/ForUsers/

Thanks,

Bill

From ken.martin at kitware.com  Fri Jun  2 08:55:09 2017
From: ken.martin at kitware.com (Ken Martin)
Date: Fri, 2 Jun 2017 08:55:09 -0400
Subject: [vtk-developers] Is someone working on the bigmac failures?
Message-ID: <CANXz0SYnT9Sp9ynhsPQTtRFGio3eZmQn2buCPZzqrtXwiQsG7Q@mail.gmail.com>

I believe I heard that we changed out the hardware to be a retina display,
is someone looking at fixing the buildbot failures?


-- 
Ken Martin PhD
Distinguished Engineer
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170602/0f303aa2/attachment.html>

From cory.quammen at kitware.com  Fri Jun  2 09:33:40 2017
From: cory.quammen at kitware.com (Cory Quammen)
Date: Fri, 2 Jun 2017 09:33:40 -0400
Subject: [vtk-developers] Is someone working on the bigmac failures?
In-Reply-To: <CANXz0SYnT9Sp9ynhsPQTtRFGio3eZmQn2buCPZzqrtXwiQsG7Q@mail.gmail.com>
References: <CANXz0SYnT9Sp9ynhsPQTtRFGio3eZmQn2buCPZzqrtXwiQsG7Q@mail.gmail.com>
Message-ID: <CAB5Fpx6nkaer1ASG_uhW3+3g_ft_kayQ+Wto7S87y-s+moTOVg@mail.gmail.com>

Ken,

Running some of the bigmac failing tests on my MacBook Pro, it looks
like the test image size generated is in some cases one pixel to large
in one of the dimensions for some reason, e.g.,

....
602: Failed Image Test ( fieldToUGrid.png ) : 1e+299
602: Image differencing failed to produce an image because images are
different size:
602: Valid image: 374, 199, 0
602: Test image: 375, 199, 0
...
602: Failed Image Test ( fieldToUGrid.png ) : 1e+299
602: Image differencing failed to produce an image because images are
different size:
602: Valid image: 374, 199, 0
602: Test image: 375, 199, 0
...
635: Failed Image Test ( extractUGrid.png ) : 1e+299
635: Image differencing failed to produce an image because images are
different size:
635: Valid image: 499, 374, 0
635: Test image: 499, 375, 0
...

I haven't dug deeper, just posting in case this gives someone a clue.

Cory


On Fri, Jun 2, 2017 at 8:55 AM, Ken Martin <ken.martin at kitware.com> wrote:
>
> I believe I heard that we changed out the hardware to be a retina display,
> is someone looking at fixing the buildbot failures?
>
>
> --
> Ken Martin PhD
> Distinguished Engineer
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>
> _______________________________________________
> 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
>
>



-- 
Cory Quammen
Staff R&D Engineer
Kitware, Inc.

From dan.lipsa at kitware.com  Fri Jun  2 09:47:15 2017
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Fri, 2 Jun 2017 09:47:15 -0400
Subject: [vtk-developers] Is someone working on the bigmac failures?
In-Reply-To: <CAB5Fpx6nkaer1ASG_uhW3+3g_ft_kayQ+Wto7S87y-s+moTOVg@mail.gmail.com>
References: <CANXz0SYnT9Sp9ynhsPQTtRFGio3eZmQn2buCPZzqrtXwiQsG7Q@mail.gmail.com>
 <CAB5Fpx6nkaer1ASG_uhW3+3g_ft_kayQ+Wto7S87y-s+moTOVg@mail.gmail.com>
Message-ID: <CADwGrVo80X8dhPZ-DDbK7ZZQR6jW5r5=pfnm-26LV6YbUmO4Fw@mail.gmail.com>

This seems to be related to the limitation for macs with retina display -
they can only create windows with width and height with even number of
pixels.
If you try to create a window with height or width with odd number of
pixels you end up with height or width with even number of pixels. See
(there is an small test there as well)

https://gitlab.kitware.com/vtk/vtk/merge_requests/2567#note_237976

But there seems to be something else going on.

Dan


On Fri, Jun 2, 2017 at 9:33 AM, Cory Quammen <cory.quammen at kitware.com>
wrote:

> Ken,
>
> Running some of the bigmac failing tests on my MacBook Pro, it looks
> like the test image size generated is in some cases one pixel to large
> in one of the dimensions for some reason, e.g.,
>
> ....
> 602: Failed Image Test ( fieldToUGrid.png ) : 1e+299
> 602: Image differencing failed to produce an image because images are
> different size:
> 602: Valid image: 374, 199, 0
> 602: Test image: 375, 199, 0
> ...
> 602: Failed Image Test ( fieldToUGrid.png ) : 1e+299
> 602: Image differencing failed to produce an image because images are
> different size:
> 602: Valid image: 374, 199, 0
> 602: Test image: 375, 199, 0
> ...
> 635: Failed Image Test ( extractUGrid.png ) : 1e+299
> 635: Image differencing failed to produce an image because images are
> different size:
> 635: Valid image: 499, 374, 0
> 635: Test image: 499, 375, 0
> ...
>
> I haven't dug deeper, just posting in case this gives someone a clue.
>
> Cory
>
>
> On Fri, Jun 2, 2017 at 8:55 AM, Ken Martin <ken.martin at kitware.com> wrote:
> >
> > I believe I heard that we changed out the hardware to be a retina
> display,
> > is someone looking at fixing the buildbot failures?
> >
> >
> > --
> > Ken Martin PhD
> > Distinguished Engineer
> > Kitware Inc.
> > 28 Corporate Drive
> > Clifton Park NY 12065
> >
> > This communication, including all attachments, contains confidential and
> > legally privileged information, and it is intended only for the use of
> the
> > addressee.  Access to this email by anyone else is unauthorized. If you
> are
> > not the intended recipient, any disclosure, copying, distribution or any
> > action taken in reliance on it is prohibited and may be unlawful. If you
> > received this communication in error please notify us immediately and
> > destroy the original message.  Thank you.
> >
> > _______________________________________________
> > 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
> >
> >
>
>
>
> --
> Cory Quammen
> Staff R&D Engineer
> Kitware, Inc.
> _______________________________________________
> 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/20170602/7db6928c/attachment.html>

From marcus.hanwell at kitware.com  Fri Jun  2 10:07:51 2017
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Fri, 2 Jun 2017 10:07:51 -0400
Subject: [vtk-developers] Is someone working on the bigmac failures?
In-Reply-To: <CANXz0SYnT9Sp9ynhsPQTtRFGio3eZmQn2buCPZzqrtXwiQsG7Q@mail.gmail.com>
References: <CANXz0SYnT9Sp9ynhsPQTtRFGio3eZmQn2buCPZzqrtXwiQsG7Q@mail.gmail.com>
Message-ID: <CAMkPkZUeLd-DFEdWWaJA4MDX=e0Bs8iZoCehoLrYPX8S4T=4bQ@mail.gmail.com>

On Fri, Jun 2, 2017 at 8:55 AM, Ken Martin <ken.martin at kitware.com> wrote:

>
> I believe I heard that we changed out the hardware to be a retina display,
> is someone looking at fixing the buildbot failures?
>

Not working on it, but just to confirm that it's primary display was
replaced with a 4k retina monitor, no other changes were made.

Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170602/3cba6ef2/attachment.html>

From sean at rogue-research.com  Fri Jun  2 11:54:35 2017
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 2 Jun 2017 11:54:35 -0400
Subject: [vtk-developers] Is someone working on the bigmac failures?
In-Reply-To: <CAB5Fpx6nkaer1ASG_uhW3+3g_ft_kayQ+Wto7S87y-s+moTOVg@mail.gmail.com>
References: <CANXz0SYnT9Sp9ynhsPQTtRFGio3eZmQn2buCPZzqrtXwiQsG7Q@mail.gmail.com>
 <CAB5Fpx6nkaer1ASG_uhW3+3g_ft_kayQ+Wto7S87y-s+moTOVg@mail.gmail.com>
Message-ID: <20170602155435.646162128@mail.rogue-research.com>

On Fri, 2 Jun 2017 09:33:40 -0400, Cory Quammen said:

>Running some of the bigmac failing tests on my MacBook Pro, it looks
>like the test image size generated is in some cases one pixel to large
>in one of the dimensions for some reason, e.g.,
>
>....
>602: Failed Image Test ( fieldToUGrid.png ) : 1e+299
>602: Image differencing failed to produce an image because images are
>different size:
>602: Valid image: 374, 199, 0
>602: Test image: 375, 199, 0

Would it be hard / what would be involved in: changing all tests and images to have an even number of pixels in width and height?  (Multiple of 4 might be even more future-proof against future very HiDPI displays.)

Cheers,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From david.gobbi at gmail.com  Fri Jun  2 12:01:33 2017
From: david.gobbi at gmail.com (David Gobbi)
Date: Fri, 2 Jun 2017 10:01:33 -0600
Subject: [vtk-developers] Is someone working on the bigmac failures?
In-Reply-To: <20170602155435.646162128@mail.rogue-research.com>
References: <CANXz0SYnT9Sp9ynhsPQTtRFGio3eZmQn2buCPZzqrtXwiQsG7Q@mail.gmail.com>
 <CAB5Fpx6nkaer1ASG_uhW3+3g_ft_kayQ+Wto7S87y-s+moTOVg@mail.gmail.com>
 <20170602155435.646162128@mail.rogue-research.com>
Message-ID: <CANwS1=GfParPcP8weReq1OjuKD5sdo9dUWN1Vb8PzHhAE-1tCw@mail.gmail.com>

On Fri, Jun 2, 2017 at 9:54 AM, Sean McBride <sean at rogue-research.com>
wrote:
>
>
> Would it be hard / what would be involved in: changing all tests and
> images to have an even number of pixels in width and height?  (Multiple of
> 4 might be even more future-proof against future very HiDPI displays.)


It would be easier to change the testing so that it tolerates a 1-pixel
difference in the size in the images.  In the future the tolerance could be
increased as necessary.

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170602/10564a56/attachment.html>

From jhlegarreta at vicomtech.org  Sun Jun  4 15:39:58 2017
From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta)
Date: Sun, 4 Jun 2017 21:39:58 +0200
Subject: [vtk-developers] ANN: VTKWikiExamples are now VTKExamples
In-Reply-To: <CADZJ4hNVHcdi3Wj=yMGcqNfk+c=oFcxueev7k+Bw=kBG6mkEKg@mail.gmail.com>
References: <CADZJ4hNVHcdi3Wj=yMGcqNfk+c=oFcxueev7k+Bw=kBG6mkEKg@mail.gmail.com>
Message-ID: <CAAKhGh_K_NEbXH4++1+PZdyeRuKa5mWs47wdb-NAM0h_GStyeQ@mail.gmail.com>

Nice Bill !

I think it's been a notable and worthwhile effort: making the VTK example
contribution process and navigation easier was needed.

The contribution guide is crystal clear, and works as expected.

JON HAITZ

--


On 1 June 2017 at 17:10, Bill Lorensen <bill.lorensen at gmail.com> wrote:

> Folks,
>
> We are moving the wiki-based VTK examples: http://www.vtk.org/Wiki/VTK/
> Examples
> to a git-based repository:  https://lorensen.github.io/VTKExamples/
>
> The new VTK Examples have a more modern look and feel and perform well
> on mobile devices. The pages use Google's Material Design guidelines
> so navigation will look familiar to many users.
>
> All of the wiki examples have been moved to the new repository.
> Eventually we will decommission the old wiki-based examples.
>
> Consider this a beta announcement. We need feedback and help to fix
> the description pages.
>
> To contribute, please see these instructions:
> https://lorensen.github.io/VTKExamples/site/Instructions/ForDevelopers/
>
> To use the new examples, see the instructions here:
> https://lorensen.github.io/VTKExamples/site/Instructions/ForUsers/
>
> Thanks,
>
> Bill
> _______________________________________________
> 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/20170604/d581669b/attachment.html>

From sankhesh.jhaveri at kitware.com  Thu Jun  8 16:33:04 2017
From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri)
Date: Thu, 08 Jun 2017 20:33:04 +0000
Subject: [vtk-developers] Announce: vtk 8.0.0.rc2 ready for testing
Message-ID: <CAEcL5t4aUGNzWYE43xtX8ZMEh59-+wUVTBwXiN-28yXtmVB8XQ@mail.gmail.com>

The VTK maintenance team is happy to announce that the second release
candidate has been tagged for VTK 8.0.

You can find the source, data and documentation tarballs here:

http://www.vtk.org/download/#candidate

Changes new to this release candidate include

   - Deprecated vtkFiltersMatlab and vtkFiltersStatisticsGnuR modules
   - Removes deprecated classes like vtkStreamer, vtkStreamPoints and
   vtkStreamLine

Take a look at the VTK wiki
<http://www.vtk.org/Wiki/VTK/API_Changes_7_1_0_to_8_0_0> for a complete
list of API changes in v8.0.0 over the previous version.

Please try this version of VTK and report any issues to the VTK mailing list
<http://www.vtk.org/mailing-lists/> or the bug tracker
<https://gitlab.kitware.com/vtk/vtk/issues> so that we can try to address
them before the VTK 8.0.0 final. Kindly set the 8.0 milestone
<https://gitlab.kitware.com/vtk/vtk/milestones/6> on the issues and merge
requests to ensure that they are tracked during the remainder of the 8.0
release process. Further, please base / rebase all 8.0 target branches off
of the v8.0.0.rc2 tag <https://gitlab.kitware.com/vtk/vtk/tags/v8.0.0.rc2> (or
earlier) to ensure minimal merge conflicts with the release branch.

As always, contact Kitware <http://www.kitware.com> and the mailing lists
for assistance.

Thanks,
VTK Maintenance Team
?
-- 
Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware
<http://www.kitware.com/> | (518) 881-4417
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170608/2e64f4da/attachment.html>

From dan.lipsa at kitware.com  Thu Jun  8 16:45:09 2017
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Thu, 8 Jun 2017 16:45:09 -0400
Subject: [vtk-developers] add a directory to external data
Message-ID: <CADwGrVqx4LLqpT9VRX+1qd=ak8n7xQs6Un+E0LN1bCFOe39JKg@mail.gmail.com>

Hi all,
I am trying to add a vtm data for testing. The original data is:


[~/projects/VTK/src/Testing/Data (evenly-spaced-streamlines *%=)]$ ls clt*
clt.vtm

clt:
clt_0_0.vtr  clt_1_0.vtr

I move to the build directory and run
> cmake .


The problem I am seeing is that only the vtm file gets the md5 extension
the files inside the clt directory don't.

[~/projects/VTK/src/Testing/Data (evenly-spaced-streamlines *%=)]$ ls clt*
clt.vtm.md5

clt:
clt_0_0.vtr  clt_1_0.vtr

Any ideas?

Thanks,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170608/7aed8c80/attachment.html>

From dave.demarle at kitware.com  Thu Jun  8 16:50:24 2017
From: dave.demarle at kitware.com (David E DeMarle)
Date: Thu, 8 Jun 2017 16:50:24 -0400
Subject: [vtk-developers] add a directory to external data
In-Reply-To: <CADwGrVqx4LLqpT9VRX+1qd=ak8n7xQs6Un+E0LN1bCFOe39JKg@mail.gmail.com>
References: <CADwGrVqx4LLqpT9VRX+1qd=ak8n7xQs6Un+E0LN1bCFOe39JKg@mail.gmail.com>
Message-ID: <CANjZAi8OuGrNP9CQFBzp9VETG3AYqmS-VQfqkEhT2zQOiEf2+Q@mail.gmail.com>

You can add directories and regex's for the directory contents to External
data via ExternalData_Expand_Arguments.
See IO/Xdmf3/Testsing/Python/CMakeLists.txt for an example and
vtkModuleMacros for the implementation.


David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Thu, Jun 8, 2017 at 4:45 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:

> Hi all,
> I am trying to add a vtm data for testing. The original data is:
>
>
> [~/projects/VTK/src/Testing/Data (evenly-spaced-streamlines *%=)]$ ls clt*
> clt.vtm
>
> clt:
> clt_0_0.vtr  clt_1_0.vtr
>
> I move to the build directory and run
> > cmake .
>
>
> The problem I am seeing is that only the vtm file gets the md5 extension
> the files inside the clt directory don't.
>
> [~/projects/VTK/src/Testing/Data (evenly-spaced-streamlines *%=)]$ ls clt*
> clt.vtm.md5
>
> clt:
> clt_0_0.vtr  clt_1_0.vtr
>
> Any ideas?
>
> Thanks,
> Dan
>
>
> _______________________________________________
> 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/20170608/0e61e251/attachment.html>

From elvis.stansvik at orexplore.com  Fri Jun  9 02:28:09 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 9 Jun 2017 08:28:09 +0200
Subject: [vtk-developers] [vtkusers] Announce: vtk 8.0.0.rc2 ready for
	testing
In-Reply-To: <CAEcL5t4aUGNzWYE43xtX8ZMEh59-+wUVTBwXiN-28yXtmVB8XQ@mail.gmail.com>
References: <CAEcL5t4aUGNzWYE43xtX8ZMEh59-+wUVTBwXiN-28yXtmVB8XQ@mail.gmail.com>
Message-ID: <CAE-7VJm2mV+qtSRQoMCtHSZ-R37zEvmeFm33L13__b_5Tin2tQ@mail.gmail.com>

Hi Sankhesh,

Nice to see rc2 out, it has a fix for a problem I reported (thanks!). I'll
update our software probably later today.

See below though.

Den 8 juni 2017 10:33 em skrev "Sankhesh Jhaveri" <
sankhesh.jhaveri at kitware.com>:
>
> The VTK maintenance team is happy to announce that the second release
candidate has been tagged for VTK 8.0.
>
> You can find the source, data and documentation tarballs here:
>
> http://www.vtk.org/download/#candidate
>
> Changes new to this release candidate include
>
> Deprecated vtkFiltersMatlab and vtkFiltersStatisticsGnuR modules
> Removes deprecated classes like vtkStreamer, vtkStreamPoints and
vtkStreamLine
>
> Take a look at the VTK wiki for a complete list of API changes in v8.0.0
over the previous version.
>
> Please try this version of VTK and report any issues to the VTK mailing
list or the bug tracker so that we can try to address them before the VTK
8.0.0 final. Kindly set the 8.0 milestone on the issues and merge requests
to ensure that they are tracked during the remainder of the 8.0 release
process.

Just wanted to remind about

https://gitlab.kitware.com/vtk/vtk/issues/17058

which I think should be a blocker for 8.0.0. I couldn't find a way to set
the milestone when I reported, but I guess I just don't have the necessary
bits.

Just wanted to promote this issue a little, as I was afraid it was falling
through the cracks.

Thanks,
Elvis

Further, please base / rebase all 8.0 target branches off of the v8.0.0.rc2
tag (or earlier) to ensure minimal merge conflicts with the release branch.
>
> As always, contact Kitware and the mailing lists for assistance.
>
> Thanks,
> VTK Maintenance Team
>
> ?
> --
> Sankhesh Jhaveri
> Sr. Research & Development Engineer | Kitware | (518) 881-4417
> ?
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170609/a2af73af/attachment-0001.html>

From dave.demarle at kitware.com  Fri Jun  9 06:56:25 2017
From: dave.demarle at kitware.com (David E DeMarle)
Date: Fri, 9 Jun 2017 06:56:25 -0400
Subject: [vtk-developers] Announce: vtk 8.0.0.rc2 ready for testing
In-Reply-To: <CAE-7VJm2mV+qtSRQoMCtHSZ-R37zEvmeFm33L13__b_5Tin2tQ@mail.gmail.com>
References: <CAEcL5t4aUGNzWYE43xtX8ZMEh59-+wUVTBwXiN-28yXtmVB8XQ@mail.gmail.com>
 <CAE-7VJm2mV+qtSRQoMCtHSZ-R37zEvmeFm33L13__b_5Tin2tQ@mail.gmail.com>
Message-ID: <CANjZAi85go5Z9MB0bcsGU81OhiDOkiD5C8r-py92FuSEdvebWA@mail.gmail.com>

We appreciate the reminder.

We did consider that issue in rc2 but are unsure yet if a fix will be in
time for 8.0.0. If not, we'll make a .1 patch release as soon as the fix is
in master.

Thanks

On Friday, June 9, 2017, Elvis Stansvik <elvis.stansvik at orexplore.com>
wrote:

> Hi Sankhesh,
>
> Nice to see rc2 out, it has a fix for a problem I reported (thanks!). I'll
> update our software probably later today.
>
> See below though.
>
> Den 8 juni 2017 10:33 em skrev "Sankhesh Jhaveri" <
> sankhesh.jhaveri at kitware.com
> <javascript:_e(%7B%7D,'cvml','sankhesh.jhaveri at kitware.com');>>:
> >
> > The VTK maintenance team is happy to announce that the second release
> candidate has been tagged for VTK 8.0.
> >
> > You can find the source, data and documentation tarballs here:
> >
> > http://www.vtk.org/download/#candidate
> >
> > Changes new to this release candidate include
> >
> > Deprecated vtkFiltersMatlab and vtkFiltersStatisticsGnuR modules
> > Removes deprecated classes like vtkStreamer, vtkStreamPoints and
> vtkStreamLine
> >
> > Take a look at the VTK wiki for a complete list of API changes in v8.0.0
> over the previous version.
> >
> > Please try this version of VTK and report any issues to the VTK mailing
> list or the bug tracker so that we can try to address them before the VTK
> 8.0.0 final. Kindly set the 8.0 milestone on the issues and merge requests
> to ensure that they are tracked during the remainder of the 8.0 release
> process.
>
> Just wanted to remind about
>
> https://gitlab.kitware.com/vtk/vtk/issues/17058
>
> which I think should be a blocker for 8.0.0. I couldn't find a way to set
> the milestone when I reported, but I guess I just don't have the necessary
> bits.
>
> Just wanted to promote this issue a little, as I was afraid it was falling
> through the cracks.
>
> Thanks,
> Elvis
>
> Further, please base / rebase all 8.0 target branches off of the
> v8.0.0.rc2 tag (or earlier) to ensure minimal merge conflicts with the
> release branch.
> >
> > As always, contact Kitware and the mailing lists for assistance.
> >
> > Thanks,
> > VTK Maintenance Team
> >
> > ?
> > --
> > Sankhesh Jhaveri
> > Sr. Research & Development Engineer | Kitware | (518) 881-4417
> > ?
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
> >
> > Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
> >
> > Search the list archives at: http://markmail.org/search/?q=vtkusers
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtkusers
> >
>


-- 
David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170609/bd981912/attachment.html>

From elvis.stansvik at orexplore.com  Fri Jun  9 07:16:29 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 9 Jun 2017 13:16:29 +0200
Subject: [vtk-developers] Announce: vtk 8.0.0.rc2 ready for testing
In-Reply-To: <CANjZAi85go5Z9MB0bcsGU81OhiDOkiD5C8r-py92FuSEdvebWA@mail.gmail.com>
References: <CAEcL5t4aUGNzWYE43xtX8ZMEh59-+wUVTBwXiN-28yXtmVB8XQ@mail.gmail.com>
 <CAE-7VJm2mV+qtSRQoMCtHSZ-R37zEvmeFm33L13__b_5Tin2tQ@mail.gmail.com>
 <CANjZAi85go5Z9MB0bcsGU81OhiDOkiD5C8r-py92FuSEdvebWA@mail.gmail.com>
Message-ID: <CAE-7VJmxGJdFuHY_rLurF3XbhgRTUzYtMB9xY6qMF8GohHQmbw@mail.gmail.com>

2017-06-09 12:56 GMT+02:00 David E DeMarle <dave.demarle at kitware.com>:

> We appreciate the reminder.
>
> We did consider that issue in rc2 but are unsure yet if a fix will be in
> time for 8.0.0. If not, we'll make a .1 patch release as soon as the fix is
> in master.
>

Alright, perfectly understandable. In fact, I don't think anyone really
know yet where the bug comes from. Ken thought it might be QTBUG-60742
rearing its head, but that's not it it seems.

But I hope it's a priority, since it means volume rendering is broken on
the 4xxx Intel GPUs for all apps using the new QVTKOpenGLWidget.

Let me know if there's something I can do to help debug it.

Elvis


>
> Thanks
>
>
> On Friday, June 9, 2017, Elvis Stansvik <elvis.stansvik at orexplore.com>
> wrote:
>
>> Hi Sankhesh,
>>
>> Nice to see rc2 out, it has a fix for a problem I reported (thanks!).
>> I'll update our software probably later today.
>>
>> See below though.
>>
>> Den 8 juni 2017 10:33 em skrev "Sankhesh Jhaveri" <
>> sankhesh.jhaveri at kitware.com>:
>> >
>> > The VTK maintenance team is happy to announce that the second release
>> candidate has been tagged for VTK 8.0.
>> >
>> > You can find the source, data and documentation tarballs here:
>> >
>> > http://www.vtk.org/download/#candidate
>> >
>> > Changes new to this release candidate include
>> >
>> > Deprecated vtkFiltersMatlab and vtkFiltersStatisticsGnuR modules
>> > Removes deprecated classes like vtkStreamer, vtkStreamPoints and
>> vtkStreamLine
>> >
>> > Take a look at the VTK wiki for a complete list of API changes in
>> v8.0.0 over the previous version.
>> >
>> > Please try this version of VTK and report any issues to the VTK mailing
>> list or the bug tracker so that we can try to address them before the VTK
>> 8.0.0 final. Kindly set the 8.0 milestone on the issues and merge requests
>> to ensure that they are tracked during the remainder of the 8.0 release
>> process.
>>
>> Just wanted to remind about
>>
>> https://gitlab.kitware.com/vtk/vtk/issues/17058
>>
>> which I think should be a blocker for 8.0.0. I couldn't find a way to set
>> the milestone when I reported, but I guess I just don't have the necessary
>> bits.
>>
>> Just wanted to promote this issue a little, as I was afraid it was
>> falling through the cracks.
>>
>> Thanks,
>> Elvis
>>
>> Further, please base / rebase all 8.0 target branches off of the
>> v8.0.0.rc2 tag (or earlier) to ensure minimal merge conflicts with the
>> release branch.
>> >
>> > As always, contact Kitware and the mailing lists for assistance.
>> >
>> > Thanks,
>> > VTK Maintenance Team
>> >
>> > ?
>> > --
>> > Sankhesh Jhaveri
>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417
>> > ?
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> >
>> > Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>> >
>> > Search the list archives at: http://markmail.org/search/?q=vtkusers
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/vtkusers
>> >
>>
>
>
> --
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909 <%28518%29%20881-4909>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170609/c3f4dfc8/attachment.html>

From brad.king at kitware.com  Fri Jun  9 08:48:00 2017
From: brad.king at kitware.com (Brad King)
Date: Fri, 9 Jun 2017 08:48:00 -0400
Subject: [vtk-developers] add a directory to external data
In-Reply-To: <CANjZAi8OuGrNP9CQFBzp9VETG3AYqmS-VQfqkEhT2zQOiEf2+Q@mail.gmail.com>
References: <CADwGrVqx4LLqpT9VRX+1qd=ak8n7xQs6Un+E0LN1bCFOe39JKg@mail.gmail.com>
 <CANjZAi8OuGrNP9CQFBzp9VETG3AYqmS-VQfqkEhT2zQOiEf2+Q@mail.gmail.com>
Message-ID: <cd514aa9-0337-ff8a-3225-1d624f709ed5@kitware.com>

On 06/08/2017 04:50 PM, David E DeMarle wrote:
> You can add directories and regex's for the directory contents to
> External data via ExternalData_Expand_Arguments.

Yes.  See docs here:

  https://cmake.org/cmake/help/v3.9/module/ExternalData.html#referencing-directories

There is also an option to recurse if needed.

-Brad


From dan.lipsa at kitware.com  Fri Jun  9 09:47:25 2017
From: dan.lipsa at kitware.com (Dan Lipsa)
Date: Fri, 9 Jun 2017 09:47:25 -0400
Subject: [vtk-developers] add a directory to external data
In-Reply-To: <CANjZAi8OuGrNP9CQFBzp9VETG3AYqmS-VQfqkEhT2zQOiEf2+Q@mail.gmail.com>
References: <CADwGrVqx4LLqpT9VRX+1qd=ak8n7xQs6Un+E0LN1bCFOe39JKg@mail.gmail.com>
 <CANjZAi8OuGrNP9CQFBzp9VETG3AYqmS-VQfqkEhT2zQOiEf2+Q@mail.gmail.com>
Message-ID: <CADwGrVpF3hVK1R1nwp56XWM_nh7HeH7_Ctnbgpi7wjqRGSavKQ@mail.gmail.com>

That works.

Thanks Dave!

On Thu, Jun 8, 2017 at 4:50 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> You can add directories and regex's for the directory contents to External
> data via ExternalData_Expand_Arguments.
> See IO/Xdmf3/Testsing/Python/CMakeLists.txt for an example and
> vtkModuleMacros for the implementation.
>
>
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909 <(518)%20881-4909>
>
> On Thu, Jun 8, 2017 at 4:45 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
>
>> Hi all,
>> I am trying to add a vtm data for testing. The original data is:
>>
>>
>> [~/projects/VTK/src/Testing/Data (evenly-spaced-streamlines *%=)]$ ls
>> clt*
>> clt.vtm
>>
>> clt:
>> clt_0_0.vtr  clt_1_0.vtr
>>
>> I move to the build directory and run
>> > cmake .
>>
>>
>> The problem I am seeing is that only the vtm file gets the md5 extension
>> the files inside the clt directory don't.
>>
>> [~/projects/VTK/src/Testing/Data (evenly-spaced-streamlines *%=)]$ ls
>> clt*
>> clt.vtm.md5
>>
>> clt:
>> clt_0_0.vtr  clt_1_0.vtr
>>
>> Any ideas?
>>
>> Thanks,
>> Dan
>>
>>
>> _______________________________________________
>> 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/20170609/4eca510b/attachment-0001.html>

From sankhesh.jhaveri at kitware.com  Mon Jun 12 09:25:43 2017
From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri)
Date: Mon, 12 Jun 2017 13:25:43 +0000
Subject: [vtk-developers] [vtkusers] Announce: vtk 8.0.0.rc2 ready for
	testing
In-Reply-To: <4555350.10912853.1497085930965@mail.yahoo.com>
References: <CAEcL5t4aUGNzWYE43xtX8ZMEh59-+wUVTBwXiN-28yXtmVB8XQ@mail.gmail.com>
 <4555350.10912853.1497085930965@mail.yahoo.com>
Message-ID: <CAEcL5t5N1zskq_QZ9nKT9ni9QVesVwmCg0=Ukkva6Ryki4LgMA@mail.gmail.com>

Hello Leonid,

Please use vtkStreamTracer
<http://www.vtk.org/doc/nightly/html/classvtkStreamTracer.html> as the
replacement for vtkStreamer and its associated classes.

Please use vtkGPUVolumeRayCastMapper over the vtkVolumeTextureMapper
classes.

Thanks,
Sankhesh



On Sat, Jun 10, 2017 at 5:12 AM Leonid Dulman leonid_dulman at yahoo.co.uk
<http://mailto:leonid_dulman at yahoo.co.uk> wrote:

vtkStreamer and vtkStreamLine classes are removed from VTK 8.0.0 what I can
> use instead ?
> What method I can use instead removed vtkVolumeTextureMapper2D:Render
> vtkVolumeTextureMapper3D:Render
>
> Thank you
>
>
> ------------------------------
> *From:* Sankhesh Jhaveri <sankhesh.jhaveri at kitware.com>
> *To:* vtk-developers <vtk-developers at vtk.org>; "vtkusers at vtk.org" <
> vtkusers at vtk.org>
> *Sent:* Thursday, June 8, 2017 11:33 PM
> *Subject:* [vtkusers] Announce: vtk 8.0.0.rc2 ready for testing
>
> The VTK maintenance team is happy to announce that the second release
> candidate has been tagged for VTK 8.0.
> You can find the source, data and documentation tarballs here:
> http://www.vtk.org/download/#candidate
> Changes new to this release candidate include
>
>    - Deprecated vtkFiltersMatlab and vtkFiltersStatisticsGnuR modules
>    - Removes deprecated classes like vtkStreamer, vtkStreamPoints and
>    vtkStreamLine
>
> Take a look at the VTK wiki
> <http://www.vtk.org/Wiki/VTK/API_Changes_7_1_0_to_8_0_0> for a complete
> list of API changes in v8.0.0 over the previous version.
> Please try this version of VTK and report any issues to the VTK mailing
> list <http://www.vtk.org/mailing-lists/> or the bug tracker
> <https://gitlab.kitware.com/vtk/vtk/issues> so that we can try to address
> them before the VTK 8.0.0 final. Kindly set the 8.0 milestone
> <https://gitlab.kitware.com/vtk/vtk/milestones/6> on the issues and merge
> requests to ensure that they are tracked during the remainder of the 8.0
> release process. Further, please base / rebase all 8.0 target branches off
> of the v8.0.0.rc2 tag <https://gitlab.kitware.com/vtk/vtk/tags/v8.0.0.rc2> (or
> earlier) to ensure minimal merge conflicts with the release branch.
> As always, contact Kitware <http://www.kitware.com/> and the mailing
> lists for assistance.
> Thanks,
> VTK Maintenance Team
> ?
> --
> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware
> <http://www.kitware.com/> | (518) 881-4417
> ?
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
>
>

?
-- 
Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware
<http://www.kitware.com/> | (518) 881-4417
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170612/bb93a3bb/attachment-0001.html>

From david.gobbi at gmail.com  Mon Jun 12 14:16:07 2017
From: david.gobbi at gmail.com (David Gobbi)
Date: Mon, 12 Jun 2017 12:16:07 -0600
Subject: [vtk-developers] Comparing doubles with floats: precision issues
Message-ID: <CANwS1=FfXPU9ckJDCrPpd6VvyUcy=djDuFABT2uTyz0AcA-+ZA@mail.gmail.com>

Hi All,

This is one of those picky math questions that deals with numerical
precision.  Let's say that one has a data set with scalar type "float", and
wants to select values within a range (minval, maxval) where minval, maxval
are of type "double":

    if (fval >= minval && fval <= maxval) { ... }

Now let's say you don't want "fval" to be converted to double, because
floats are faster than doubles on your hardware:

   float fminval = static_cast<float>(minval);
   float fmaxval = static_cast<float>(maxval);
   ...
   if (fval >= fminval && fval <= fmaxval) { ... }

Unfortunately, there are some cases where fval <= fmaxval even though fval
> maxval.  Reducing the precision of the range has invalidated the check.
In order to fix things, you must choose fminval to be the value closest to
but not more than minval, and choose fmaxval to be the value closest to but
not less than maxval.

    float fminval = NearestFloatNotGreaterThan(minval);
    float fmaxval = NearestFloatNotLessThan(maxval);

With these, (fval >= fminval && fval <= fmaxval) gives the same result as
(fval >= minval && val <= fmaxval) and all is right with the world.

So my question is, have any other devs created a solution for this issue,
either for VTK or for related code?  I'm considering a solution based on
the C++11 function std::nextafter(), as described on this stackoverflow
page:
https://stackoverflow.com/questions/15294046/round-a-double-to-the-closest-and-greater-float

 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170612/1f2c4385/attachment.html>

From sankhesh.jhaveri at kitware.com  Wed Jun 14 14:02:31 2017
From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri)
Date: Wed, 14 Jun 2017 18:02:31 +0000
Subject: [vtk-developers] vtkOBJImporter associated MTL files
Message-ID: <CAEcL5t62GEsc9S6E+CnbM075qSc4-RV-dOpohuhjjT5Xn5DC-Q@mail.gmail.com>

Hello devs,

Recently, we?ve started running into issues with vtkOBJImporter because it
assumes that there is always an associated MTL file (with the same name)
available next to the OBJ file. Merge request #2933
<https://gitlab.kitware.com/vtk/vtk/merge_requests/2933> addresses this.
Since this changes the behavior of the importer, I want to make sure that
there are no objections before merging. Please let me know if there is a
strong use-case for keeping the assumption.

Thanks,
Sankhesh
?
-- 
Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware
<http://www.kitware.com/> | (518) 881-4417
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170614/d19b010e/attachment.html>

From david.gobbi at gmail.com  Fri Jun 16 08:37:52 2017
From: david.gobbi at gmail.com (David Gobbi)
Date: Fri, 16 Jun 2017 06:37:52 -0600
Subject: [vtk-developers] More zero-copy array support for Python
Message-ID: <CANwS1=E=dE+kHKgg5vqtm-_NR43GqTnbH0kKa4h8=x5zVcBguQ@mail.gmail.com>

Hi All,

Yesterday I merged the wrapping of the vtkSOADataArrays, and also added a
new wrapper hint to assist with VTK's zero-copy methods.

Zero-copy is when an array uses an existing block of memory.  In the Python
wrappers, this generally means making a VTK array from a numpy array or
vice-versa.  Or making a VTK image from a PIL image.  Or using memmap to
share a VTK data set among multiple processes.

The new wrapper hint VTK_ZEROCOPY can be applied to method parameters that
are used for zero-copy operations:

  void vtkFloatArray::SetArray(VTK_ZEROCOPY float *ptr, vtkIdType n, int
save);

This hint allows the Python wrappers to do the zero-copy magic with
SetArray:

  import numpy
  import vtk
  c = numpy.array([1,2,3], 'f')
  a = vtk.vtkFloatArray()
  a.SetArray(c, c.size, True)
  a.array = c  # keep reference to "c"

Astute VTKers will note that this was already possible with SetVoidArray(),
as used by the vtk.numpy_support module, but SetArray() adds type checking.

Also, SetArray() works with the newly-wrapped vtkSOADataArrays, so perhaps
in the future numpy_support.numpy_to_vtk() can be expanded to support SOA
arrays:

  c0 = numpy.array([1,2,3], 'f')
  c1 = numpy.array([4,5,6], 'f')
  a = vtk.vtkSOADataArrayTemplate[c0.dtype]()
  a.SetNumberOfComponents(2)
  a.SetArray(0, c0, c0.size, True, True)
  a.SetArray(1, c1, c1.size, True, True)

In the future this could be done with  a = vtk.numpy_support.numpy_to_vtk(
(c0,c1) ).

I haven't yet implemented the mechanism to go in the other direction, i.e.
to create a numpy array from a VTK SOA array.

Also: vtkSOADataArrayTemplate is now wrapped, but vtkAOSDataArrayTemplate
is not.  Currently the wrappers think that vtkDataArray is the immediate
superclass of vtkFloatArray etc.  This could be changed, if there are use
cases for directly instantiating vtkAOSDataArrayTemplate.

Cheers,
 - David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170616/c0543b20/attachment.html>

From david.lonie at kitware.com  Fri Jun 16 09:22:42 2017
From: david.lonie at kitware.com (David Lonie)
Date: Fri, 16 Jun 2017 09:22:42 -0400
Subject: [vtk-developers] More zero-copy array support for Python
In-Reply-To: <CANwS1=E=dE+kHKgg5vqtm-_NR43GqTnbH0kKa4h8=x5zVcBguQ@mail.gmail.com>
References: <CANwS1=E=dE+kHKgg5vqtm-_NR43GqTnbH0kKa4h8=x5zVcBguQ@mail.gmail.com>
Message-ID: <CA+=e1ot-oWMZByh3+0O2XLqu8S-=VAUSiJyOmNkD5BjLSu7MXA@mail.gmail.com>

On Fri, Jun 16, 2017 at 8:37 AM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi All,
>
> Yesterday I merged the wrapping of the vtkSOADataArrays, and also added a
> new wrapper hint to assist with VTK's zero-copy methods.

This is really cool David, thanks for adding this!

> Also: vtkSOADataArrayTemplate is now wrapped, but vtkAOSDataArrayTemplate is
> not.  Currently the wrappers think that vtkDataArray is the immediate
> superclass of vtkFloatArray etc.  This could be changed, if there are use
> cases for directly instantiating vtkAOSDataArrayTemplate.

It's probably time to remove the workarounds that trick the wrappers
into thinking DataArray is the superclass of the AOSArray subclasses.
That's mainly a leftover from when the wrappers couldn't handle
templates. I suppose if it's working for SOA arrays, it should work
for AOS, too.

Dave

From berk.geveci at kitware.com  Fri Jun 16 13:18:06 2017
From: berk.geveci at kitware.com (Berk Geveci)
Date: Fri, 16 Jun 2017 13:18:06 -0400
Subject: [vtk-developers] More zero-copy array support for Python
In-Reply-To: <CANwS1=E=dE+kHKgg5vqtm-_NR43GqTnbH0kKa4h8=x5zVcBguQ@mail.gmail.com>
References: <CANwS1=E=dE+kHKgg5vqtm-_NR43GqTnbH0kKa4h8=x5zVcBguQ@mail.gmail.com>
Message-ID: <CAE32kpXPE60_gPS2eNzwaG8vGsE_7jV=se8t2+YL+HgYrr6NBQ@mail.gmail.com>

This is fantastic David!!!

One word of caution to people using numpy array -> VTK array route:

c = numpy.array([1,2,3], 'f')
a = vtk.vtkFloatArray()
a.SetArray(c, c.size, True)
a.array = c  # keep reference to "c"

This is safe only as long as you keep the a object around. If you do
something like this, you are in trouble:

pd = vtk.vtkPointData()
pd.AddArray(a)
del a

In this case, the Python object goes away and therefore releases the
reference to c. In the dataset_adapter module, I implemented a way around
this issue. I suggest taking a look at that which is in
the numpyTovtkDataArray() method.

Best,
-berk



On Fri, Jun 16, 2017 at 8:37 AM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi All,
>
> Yesterday I merged the wrapping of the vtkSOADataArrays, and also added a
> new wrapper hint to assist with VTK's zero-copy methods.
>
> Zero-copy is when an array uses an existing block of memory.  In the
> Python wrappers, this generally means making a VTK array from a numpy array
> or vice-versa.  Or making a VTK image from a PIL image.  Or using memmap to
> share a VTK data set among multiple processes.
>
> The new wrapper hint VTK_ZEROCOPY can be applied to method parameters that
> are used for zero-copy operations:
>
>   void vtkFloatArray::SetArray(VTK_ZEROCOPY float *ptr, vtkIdType n, int
> save);
>
> This hint allows the Python wrappers to do the zero-copy magic with
> SetArray:
>
>   import numpy
>   import vtk
>   c = numpy.array([1,2,3], 'f')
>   a = vtk.vtkFloatArray()
>   a.SetArray(c, c.size, True)
>   a.array = c  # keep reference to "c"
>
> Astute VTKers will note that this was already possible with
> SetVoidArray(), as used by the vtk.numpy_support module, but SetArray()
> adds type checking.
>
> Also, SetArray() works with the newly-wrapped vtkSOADataArrays, so perhaps
> in the future numpy_support.numpy_to_vtk() can be expanded to support SOA
> arrays:
>
>   c0 = numpy.array([1,2,3], 'f')
>   c1 = numpy.array([4,5,6], 'f')
>   a = vtk.vtkSOADataArrayTemplate[c0.dtype]()
>   a.SetNumberOfComponents(2)
>   a.SetArray(0, c0, c0.size, True, True)
>   a.SetArray(1, c1, c1.size, True, True)
>
> In the future this could be done with  a = vtk.numpy_support.numpy_to_vtk(
> (c0,c1) ).
>
> I haven't yet implemented the mechanism to go in the other direction, i.e.
> to create a numpy array from a VTK SOA array.
>
> Also: vtkSOADataArrayTemplate is now wrapped, but vtkAOSDataArrayTemplate
> is not.  Currently the wrappers think that vtkDataArray is the immediate
> superclass of vtkFloatArray etc.  This could be changed, if there are use
> cases for directly instantiating vtkAOSDataArrayTemplate.
>
> Cheers,
>  - 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/20170616/afe635df/attachment.html>

From david.gobbi at gmail.com  Fri Jun 16 15:12:52 2017
From: david.gobbi at gmail.com (David Gobbi)
Date: Fri, 16 Jun 2017 13:12:52 -0600
Subject: [vtk-developers] More zero-copy array support for Python
In-Reply-To: <CAE32kpXPE60_gPS2eNzwaG8vGsE_7jV=se8t2+YL+HgYrr6NBQ@mail.gmail.com>
References: <CANwS1=E=dE+kHKgg5vqtm-_NR43GqTnbH0kKa4h8=x5zVcBguQ@mail.gmail.com>
 <CAE32kpXPE60_gPS2eNzwaG8vGsE_7jV=se8t2+YL+HgYrr6NBQ@mail.gmail.com>
Message-ID: <CANwS1=F7aUO-0Of1BJbaGHiXcDEv_WB68z73voCHh2Pe-dJMUA@mail.gmail.com>

Hi Berk,

That shouldn't be the case.  When a vtk-python object destructs, its
attributes aren't deleted until a future GC cycle determines that the
vtk-c++ object has destructed.  E.g.:

c = numpy.array([1,2,3], 'f')
a = vtk.vtkFloatArray()
a.SetArray(c, c.size, True)
a.array = c

pd = vtk.vtkPointData()
pd.AddArray(a)
del a
del c

a = pd.GetArray(0)
a.array
-> array([ 1.,  2.,  3.], dtype=float32)

This behavior is tested in Common/Core/Testing/Python/TestGhost.py.  But I
notice that numpy_to_vtk() doesn't use this trick...

There could also be other isues that I'm not aware of, so I can look at
this in more depth.

 - David



On Fri, Jun 16, 2017 at 11:18 AM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> This is fantastic David!!!
>
> One word of caution to people using numpy array -> VTK array route:
>
> c = numpy.array([1,2,3], 'f')
> a = vtk.vtkFloatArray()
> a.SetArray(c, c.size, True)
> a.array = c  # keep reference to "c"
>
> This is safe only as long as you keep the a object around. If you do
> something like this, you are in trouble:
>
> pd = vtk.vtkPointData()
> pd.AddArray(a)
> del a
>
> In this case, the Python object goes away and therefore releases the
> reference to c. In the dataset_adapter module, I implemented a way around
> this issue. I suggest taking a look at that which is in
> the numpyTovtkDataArray() method.
>
> Best,
> -berk
>
>
>
> On Fri, Jun 16, 2017 at 8:37 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
>
>> Hi All,
>>
>> Yesterday I merged the wrapping of the vtkSOADataArrays, and also added a
>> new wrapper hint to assist with VTK's zero-copy methods.
>>
>> Zero-copy is when an array uses an existing block of memory.  In the
>> Python wrappers, this generally means making a VTK array from a numpy array
>> or vice-versa.  Or making a VTK image from a PIL image.  Or using memmap to
>> share a VTK data set among multiple processes.
>>
>> The new wrapper hint VTK_ZEROCOPY can be applied to method parameters
>> that are used for zero-copy operations:
>>
>>   void vtkFloatArray::SetArray(VTK_ZEROCOPY float *ptr, vtkIdType n, int
>> save);
>>
>> This hint allows the Python wrappers to do the zero-copy magic with
>> SetArray:
>>
>>   import numpy
>>   import vtk
>>   c = numpy.array([1,2,3], 'f')
>>   a = vtk.vtkFloatArray()
>>   a.SetArray(c, c.size, True)
>>   a.array = c  # keep reference to "c"
>>
>> Astute VTKers will note that this was already possible with
>> SetVoidArray(), as used by the vtk.numpy_support module, but SetArray()
>> adds type checking.
>>
>> Also, SetArray() works with the newly-wrapped vtkSOADataArrays, so
>> perhaps in the future numpy_support.numpy_to_vtk() can be expanded to
>> support SOA arrays:
>>
>>   c0 = numpy.array([1,2,3], 'f')
>>   c1 = numpy.array([4,5,6], 'f')
>>   a = vtk.vtkSOADataArrayTemplate[c0.dtype]()
>>   a.SetNumberOfComponents(2)
>>   a.SetArray(0, c0, c0.size, True, True)
>>   a.SetArray(1, c1, c1.size, True, True)
>>
>> In the future this could be done with  a = vtk.numpy_support.numpy_to_vtk(
>> (c0,c1) ).
>>
>> I haven't yet implemented the mechanism to go in the other direction,
>> i.e. to create a numpy array from a VTK SOA array.
>>
>> Also: vtkSOADataArrayTemplate is now wrapped, but vtkAOSDataArrayTemplate
>> is not.  Currently the wrappers think that vtkDataArray is the immediate
>> superclass of vtkFloatArray etc.  This could be changed, if there are use
>> cases for directly instantiating vtkAOSDataArrayTemplate.
>>
>> Cheers,
>>  - David
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170616/8bb7e2ad/attachment.html>

From berk.geveci at kitware.com  Fri Jun 16 15:53:20 2017
From: berk.geveci at kitware.com (Berk Geveci)
Date: Fri, 16 Jun 2017 15:53:20 -0400
Subject: [vtk-developers] More zero-copy array support for Python
In-Reply-To: <CANwS1=F7aUO-0Of1BJbaGHiXcDEv_WB68z73voCHh2Pe-dJMUA@mail.gmail.com>
References: <CANwS1=E=dE+kHKgg5vqtm-_NR43GqTnbH0kKa4h8=x5zVcBguQ@mail.gmail.com>
 <CAE32kpXPE60_gPS2eNzwaG8vGsE_7jV=se8t2+YL+HgYrr6NBQ@mail.gmail.com>
 <CANwS1=F7aUO-0Of1BJbaGHiXcDEv_WB68z73voCHh2Pe-dJMUA@mail.gmail.com>
Message-ID: <CAE32kpUHwzMuYpj5jx1RLM=ayT2THJzAyw6bjTBXcKEdSjb_Og@mail.gmail.com>

Interesting. Is this something relatively recent? I know that this didn't
work in the past.

On Fri, Jun 16, 2017 at 3:12 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> Hi Berk,
>
> That shouldn't be the case.  When a vtk-python object destructs, its
> attributes aren't deleted until a future GC cycle determines that the
> vtk-c++ object has destructed.  E.g.:
>
> c = numpy.array([1,2,3], 'f')
> a = vtk.vtkFloatArray()
> a.SetArray(c, c.size, True)
> a.array = c
>
> pd = vtk.vtkPointData()
> pd.AddArray(a)
> del a
> del c
>
> a = pd.GetArray(0)
> a.array
> -> array([ 1.,  2.,  3.], dtype=float32)
>
> This behavior is tested in Common/Core/Testing/Python/TestGhost.py.  But
> I notice that numpy_to_vtk() doesn't use this trick...
>
> There could also be other isues that I'm not aware of, so I can look at
> this in more depth.
>
>  - David
>
>
>
> On Fri, Jun 16, 2017 at 11:18 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
>
>> This is fantastic David!!!
>>
>> One word of caution to people using numpy array -> VTK array route:
>>
>> c = numpy.array([1,2,3], 'f')
>> a = vtk.vtkFloatArray()
>> a.SetArray(c, c.size, True)
>> a.array = c  # keep reference to "c"
>>
>> This is safe only as long as you keep the a object around. If you do
>> something like this, you are in trouble:
>>
>> pd = vtk.vtkPointData()
>> pd.AddArray(a)
>> del a
>>
>> In this case, the Python object goes away and therefore releases the
>> reference to c. In the dataset_adapter module, I implemented a way around
>> this issue. I suggest taking a look at that which is in
>> the numpyTovtkDataArray() method.
>>
>> Best,
>> -berk
>>
>>
>>
>> On Fri, Jun 16, 2017 at 8:37 AM, David Gobbi <david.gobbi at gmail.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> Yesterday I merged the wrapping of the vtkSOADataArrays, and also added
>>> a new wrapper hint to assist with VTK's zero-copy methods.
>>>
>>> Zero-copy is when an array uses an existing block of memory.  In the
>>> Python wrappers, this generally means making a VTK array from a numpy array
>>> or vice-versa.  Or making a VTK image from a PIL image.  Or using memmap to
>>> share a VTK data set among multiple processes.
>>>
>>> The new wrapper hint VTK_ZEROCOPY can be applied to method parameters
>>> that are used for zero-copy operations:
>>>
>>>   void vtkFloatArray::SetArray(VTK_ZEROCOPY float *ptr, vtkIdType n,
>>> int save);
>>>
>>> This hint allows the Python wrappers to do the zero-copy magic with
>>> SetArray:
>>>
>>>   import numpy
>>>   import vtk
>>>   c = numpy.array([1,2,3], 'f')
>>>   a = vtk.vtkFloatArray()
>>>   a.SetArray(c, c.size, True)
>>>   a.array = c  # keep reference to "c"
>>>
>>> Astute VTKers will note that this was already possible with
>>> SetVoidArray(), as used by the vtk.numpy_support module, but SetArray()
>>> adds type checking.
>>>
>>> Also, SetArray() works with the newly-wrapped vtkSOADataArrays, so
>>> perhaps in the future numpy_support.numpy_to_vtk() can be expanded to
>>> support SOA arrays:
>>>
>>>   c0 = numpy.array([1,2,3], 'f')
>>>   c1 = numpy.array([4,5,6], 'f')
>>>   a = vtk.vtkSOADataArrayTemplate[c0.dtype]()
>>>   a.SetNumberOfComponents(2)
>>>   a.SetArray(0, c0, c0.size, True, True)
>>>   a.SetArray(1, c1, c1.size, True, True)
>>>
>>> In the future this could be done with  a = vtk.numpy_support.numpy_to_vtk(
>>> (c0,c1) ).
>>>
>>> I haven't yet implemented the mechanism to go in the other direction,
>>> i.e. to create a numpy array from a VTK SOA array.
>>>
>>> Also: vtkSOADataArrayTemplate is now wrapped, but
>>> vtkAOSDataArrayTemplate is not.  Currently the wrappers think that
>>> vtkDataArray is the immediate superclass of vtkFloatArray etc.  This could
>>> be changed, if there are use cases for directly instantiating
>>> vtkAOSDataArrayTemplate.
>>>
>>> Cheers,
>>>  - David
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170616/bed1a094/attachment-0001.html>

From wascott at sandia.gov  Fri Jun 16 17:28:38 2017
From: wascott at sandia.gov (Scott, W Alan)
Date: Fri, 16 Jun 2017 21:28:38 +0000
Subject: [vtk-developers] [EXTERNAL] Comparing doubles with floats:
 precision issues
In-Reply-To: <CANwS1=FfXPU9ckJDCrPpd6VvyUcy=djDuFABT2uTyz0AcA-+ZA@mail.gmail.com>
References: <CANwS1=FfXPU9ckJDCrPpd6VvyUcy=djDuFABT2uTyz0AcA-+ZA@mail.gmail.com>
Message-ID: <5bcd106d1d414b1ea33ce6084e66b84f@ES01AMSNLNT.srn.sandia.gov>

Haven?t seen a great reply, and this was a while ago, but here goes.  This is also all theoretical, from days 20 years ago when I worked on OpenGL drivers.

How about the following:

test = (minval ? static_cast<double>fval) & (static_cast<double>fval ? maxval)

Now, test will be positive if your case should pass, negative if not.  I?m sure I missed some casts above, but you can see what I am doing.  By And?ing the positive bit on the two floats, you see if result is  positive. So, either
if(test >= 0)
  succeed;
else
  not so much;

Or, if your hardware is faster in integer space (and dirty),
if (<unsigned double>test & 0x800000000k)

I suspect this whole test should run in under 10 clocks...

Be sure to test with different compilers, and especially optimized.

Alan

From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David Gobbi
Sent: Monday, June 12, 2017 12:16 PM
To: VTK Developers <vtk-developers at vtk.org>
Subject: [EXTERNAL] [vtk-developers] Comparing doubles with floats: precision issues

Hi All,

This is one of those picky math questions that deals with numerical precision.  Let's say that one has a data set with scalar type "float", and wants to select values within a range (minval, maxval) where minval, maxval are of type "double":

    if (fval >= minval && fval <= maxval) { ... }

Now let's say you don't want "fval" to be converted to double, because floats are faster than doubles on your hardware:

   float fminval = static_cast<float>(minval);
   float fmaxval = static_cast<float>(maxval);
   ...
   if (fval >= fminval && fval <= fmaxval) { ... }

Unfortunately, there are some cases where fval <= fmaxval even though fval > maxval.  Reducing the precision of the range has invalidated the check.  In order to fix things, you must choose fminval to be the value closest to but not more than minval, and choose fmaxval to be the value closest to but not less than maxval.

    float fminval = NearestFloatNotGreaterThan(minval);
    float fmaxval = NearestFloatNotLessThan(maxval);

With these, (fval >= fminval && fval <= fmaxval) gives the same result as (fval >= minval && val <= fmaxval) and all is right with the world.

So my question is, have any other devs created a solution for this issue, either for VTK or for related code?  I'm considering a solution based on the C++11 function std::nextafter(), as described on this stackoverflow page: https://stackoverflow.com/questions/15294046/round-a-double-to-the-closest-and-greater-float

 - David




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170616/cf31fe0c/attachment.html>

From david.gobbi at gmail.com  Fri Jun 16 18:21:54 2017
From: david.gobbi at gmail.com (David Gobbi)
Date: Fri, 16 Jun 2017 16:21:54 -0600
Subject: [vtk-developers] More zero-copy array support for Python
In-Reply-To: <CAE32kpUHwzMuYpj5jx1RLM=ayT2THJzAyw6bjTBXcKEdSjb_Og@mail.gmail.com>
References: <CANwS1=E=dE+kHKgg5vqtm-_NR43GqTnbH0kKa4h8=x5zVcBguQ@mail.gmail.com>
 <CAE32kpXPE60_gPS2eNzwaG8vGsE_7jV=se8t2+YL+HgYrr6NBQ@mail.gmail.com>
 <CANwS1=F7aUO-0Of1BJbaGHiXcDEv_WB68z73voCHh2Pe-dJMUA@mail.gmail.com>
 <CAE32kpUHwzMuYpj5jx1RLM=ayT2THJzAyw6bjTBXcKEdSjb_Og@mail.gmail.com>
Message-ID: <CANwS1=EZZgjexZ3tUS85iBSP-VT6hCkV6mBKpOLSpLD8+gYrCQ@mail.gmail.com>

It's a feature that was added in Oct 2010, so it probably pre-dates the
dataset_adapter.



On Fri, Jun 16, 2017 at 1:53 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Interesting. Is this something relatively recent? I know that this didn't
> work in the past.
>
> On Fri, Jun 16, 2017 at 3:12 PM, David Gobbi <david.gobbi at gmail.com>
> wrote:
>
>> Hi Berk,
>>
>> That shouldn't be the case.  When a vtk-python object destructs, its
>> attributes aren't deleted until a future GC cycle determines that the
>> vtk-c++ object has destructed.  E.g.:
>>
>> c = numpy.array([1,2,3], 'f')
>> a = vtk.vtkFloatArray()
>> a.SetArray(c, c.size, True)
>> a.array = c
>>
>> pd = vtk.vtkPointData()
>> pd.AddArray(a)
>> del a
>> del c
>>
>> a = pd.GetArray(0)
>> a.array
>> -> array([ 1.,  2.,  3.], dtype=float32)
>>
>> This behavior is tested in Common/Core/Testing/Python/TestGhost.py.  But
>> I notice that numpy_to_vtk() doesn't use this trick...
>>
>> There could also be other isues that I'm not aware of, so I can look at
>> this in more depth.
>>
>>  - David
>>
>>
>>
>> On Fri, Jun 16, 2017 at 11:18 AM, Berk Geveci <berk.geveci at kitware.com>
>> wrote:
>>
>>> This is fantastic David!!!
>>>
>>> One word of caution to people using numpy array -> VTK array route:
>>>
>>> c = numpy.array([1,2,3], 'f')
>>> a = vtk.vtkFloatArray()
>>> a.SetArray(c, c.size, True)
>>> a.array = c  # keep reference to "c"
>>>
>>> This is safe only as long as you keep the a object around. If you do
>>> something like this, you are in trouble:
>>>
>>> pd = vtk.vtkPointData()
>>> pd.AddArray(a)
>>> del a
>>>
>>> In this case, the Python object goes away and therefore releases the
>>> reference to c. In the dataset_adapter module, I implemented a way around
>>> this issue. I suggest taking a look at that which is in
>>> the numpyTovtkDataArray() method.
>>>
>>> Best,
>>> -berk
>>>
>>>
>>>
>>> On Fri, Jun 16, 2017 at 8:37 AM, David Gobbi <david.gobbi at gmail.com>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Yesterday I merged the wrapping of the vtkSOADataArrays, and also added
>>>> a new wrapper hint to assist with VTK's zero-copy methods.
>>>>
>>>> Zero-copy is when an array uses an existing block of memory.  In the
>>>> Python wrappers, this generally means making a VTK array from a numpy array
>>>> or vice-versa.  Or making a VTK image from a PIL image.  Or using memmap to
>>>> share a VTK data set among multiple processes.
>>>>
>>>> The new wrapper hint VTK_ZEROCOPY can be applied to method parameters
>>>> that are used for zero-copy operations:
>>>>
>>>>   void vtkFloatArray::SetArray(VTK_ZEROCOPY float *ptr, vtkIdType n,
>>>> int save);
>>>>
>>>> This hint allows the Python wrappers to do the zero-copy magic with
>>>> SetArray:
>>>>
>>>>   import numpy
>>>>   import vtk
>>>>   c = numpy.array([1,2,3], 'f')
>>>>   a = vtk.vtkFloatArray()
>>>>   a.SetArray(c, c.size, True)
>>>>   a.array = c  # keep reference to "c"
>>>>
>>>> Astute VTKers will note that this was already possible with
>>>> SetVoidArray(), as used by the vtk.numpy_support module, but SetArray()
>>>> adds type checking.
>>>>
>>>> Also, SetArray() works with the newly-wrapped vtkSOADataArrays, so
>>>> perhaps in the future numpy_support.numpy_to_vtk() can be expanded to
>>>> support SOA arrays:
>>>>
>>>>   c0 = numpy.array([1,2,3], 'f')
>>>>   c1 = numpy.array([4,5,6], 'f')
>>>>   a = vtk.vtkSOADataArrayTemplate[c0.dtype]()
>>>>   a.SetNumberOfComponents(2)
>>>>   a.SetArray(0, c0, c0.size, True, True)
>>>>   a.SetArray(1, c1, c1.size, True, True)
>>>>
>>>> In the future this could be done with  a =
>>>> vtk.numpy_support.numpy_to_vtk( (c0,c1) ).
>>>>
>>>> I haven't yet implemented the mechanism to go in the other direction,
>>>> i.e. to create a numpy array from a VTK SOA array.
>>>>
>>>> Also: vtkSOADataArrayTemplate is now wrapped, but
>>>> vtkAOSDataArrayTemplate is not.  Currently the wrappers think that
>>>> vtkDataArray is the immediate superclass of vtkFloatArray etc.  This could
>>>> be changed, if there are use cases for directly instantiating
>>>> vtkAOSDataArrayTemplate.
>>>>
>>>> Cheers,
>>>>  - David
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170616/ede2f4ca/attachment-0001.html>

From david.gobbi at gmail.com  Fri Jun 16 18:31:52 2017
From: david.gobbi at gmail.com (David Gobbi)
Date: Fri, 16 Jun 2017 16:31:52 -0600
Subject: [vtk-developers] [EXTERNAL] Comparing doubles with floats:
 precision issues
In-Reply-To: <5bcd106d1d414b1ea33ce6084e66b84f@ES01AMSNLNT.srn.sandia.gov>
References: <CANwS1=FfXPU9ckJDCrPpd6VvyUcy=djDuFABT2uTyz0AcA-+ZA@mail.gmail.com>
 <5bcd106d1d414b1ea33ce6084e66b84f@ES01AMSNLNT.srn.sandia.gov>
Message-ID: <CANwS1=EzpO9vY1q1ymqh25eiOwPOg3nq3DT4rZ-qXAioxdTJjg@mail.gmail.com>

Hi Alan,

Thanks for the idea, these tricks are always useful to know.  They don't
solve my issue, though, because my goal isn't just optimization.

The thing is, I already have closed classes that do "if (fval >= fminval &&
fval <= fmaxval)" where all variables are of type "float".  My problem is,
that I have a range (minval, maxval) in double-precision, and I have to
compute (fminval, fminval) in single precision to provide to the existing
code.  As described above, a naive typecast gives the wrong answer in edge
cases, which is why fminval = NearestFloatNotGreaterThan(minval) and fmaxval
= NearestFloatNotLessThan(maxval) are necessary.

Cheers,
 - David


On Fri, Jun 16, 2017 at 3:28 PM, Scott, W Alan <wascott at sandia.gov> wrote:

> Haven?t seen a great reply, and this was a while ago, but here goes.  This
> is also all theoretical, from days 20 years ago when I worked on OpenGL
> drivers.
>
>
>
> How about the following:
>
>
>
> test = (minval ? static_cast<double>fval) & (static_cast<double>fval ?
> maxval)
>
>
>
> Now, test will be positive if your case should pass, negative if not.  I?m
> sure I missed some casts above, but you can see what I am doing.  By
> And?ing the positive bit on the two floats, you see if result is  positive.
> So, either
>
> if(test >= 0)
>
>   succeed;
>
> else
>
>   not so much;
>
>
>
> Or, if your hardware is faster in integer space (and dirty),
>
> if (<unsigned double>test & 0x800000000k)
>
>
>
> I suspect this whole test should run in under 10 clocks...
>
>
>
> Be sure to test with different compilers, and especially optimized.
>
>
>
> Alan
>
>
>
> *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf
> Of *David Gobbi
> *Sent:* Monday, June 12, 2017 12:16 PM
> *To:* VTK Developers <vtk-developers at vtk.org>
> *Subject:* [EXTERNAL] [vtk-developers] Comparing doubles with floats:
> precision issues
>
>
>
> Hi All,
>
>
>
> This is one of those picky math questions that deals with numerical
> precision.  Let's say that one has a data set with scalar type "float", and
> wants to select values within a range (minval, maxval) where minval, maxval
> are of type "double":
>
>
>
>     if (fval >= minval && fval <= maxval) { ... }
>
>
>
> Now let's say you don't want "fval" to be converted to double, because
> floats are faster than doubles on your hardware:
>
>
>
>    float fminval = static_cast<float>(minval);
>
>    float fmaxval = static_cast<float>(maxval);
>
>    ...
>
>    if (fval >= fminval && fval <= fmaxval) { ... }
>
>
>
> Unfortunately, there are some cases where fval <= fmaxval even though fval
> > maxval.  Reducing the precision of the range has invalidated the check.
> In order to fix things, you must choose fminval to be the value closest to
> but not more than minval, and choose fmaxval to be the value closest to but
> not less than maxval.
>
>
>
>     float fminval = NearestFloatNotGreaterThan(minval);
>
>     float fmaxval = NearestFloatNotLessThan(maxval);
>
>
>
> With these, (fval >= fminval && fval <= fmaxval) gives the same result as
> (fval >= minval && val <= fmaxval) and all is right with the world.
>
>
>
> So my question is, have any other devs created a solution for this issue,
> either for VTK or for related code?  I'm considering a solution based on
> the C++11 function std::nextafter(), as described on this stackoverflow
> page: https://stackoverflow.com/questions/15294046/round-
> a-double-to-the-closest-and-greater-float
>
>
>
>  - David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170616/cd659fe0/attachment.html>

From jhlegarreta at vicomtech.org  Mon Jun 19 02:12:57 2017
From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta)
Date: Mon, 19 Jun 2017 08:12:57 +0200
Subject: [vtk-developers] [VTK] Coverage analysis being reported?
Message-ID: <CAAKhGh984hZcbSi_5Fa1qcd2h8vSx6184BK-s4tYohZdyOdYcA@mail.gmail.com>

Folks,
just a heads-up: is the coverage being reported lately to the dashboard? I
had to go back a few weeks (may 22nd) to see the analysis performed by
karego.

Thanks,
JON HAITZ


--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170619/0e7e25e3/attachment.html>

From dave.demarle at kitware.com  Mon Jun 19 08:06:47 2017
From: dave.demarle at kitware.com (David E DeMarle)
Date: Mon, 19 Jun 2017 08:06:47 -0400
Subject: [vtk-developers]  [VTK] Coverage analysis being reported?
In-Reply-To: <CAAKhGh984hZcbSi_5Fa1qcd2h8vSx6184BK-s4tYohZdyOdYcA@mail.gmail.com>
References: <CAAKhGh984hZcbSi_5Fa1qcd2h8vSx6184BK-s4tYohZdyOdYcA@mail.gmail.com>
Message-ID: <CANjZAi8h=-3WhV5EYbVU9e=8UB77GHSAdMO1psLcp+S0i1cEpQ@mail.gmail.com>

This and the remaining valgrind defects are correlated with my updating gcc
on the test machine to meet the c++11 requirement.
I'll take a closer look this week and figure out what the specific problem
is.

Thanks for the reminder Jon.

On Jun 19, 2017 2:13 AM, "Jon Haitz Legarreta" <jhlegarreta at vicomtech.org
<javascript:_e(%7B%7D,'cvml','jhlegarreta at vicomtech.org');>> wrote:

> Folks,
> just a heads-up: is the coverage being reported lately to the dashboard? I
> had to go back a few weeks (may 22nd) to see the analysis performed by
> karego.
>
> Thanks,
> JON HAITZ
>
>
> --
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/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
>
>
>

-- 
David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170619/6b30ef60/attachment.html>

From dave.demarle at kitware.com  Mon Jun 19 10:37:23 2017
From: dave.demarle at kitware.com (David E DeMarle)
Date: Mon, 19 Jun 2017 10:37:23 -0400
Subject: [vtk-developers] [VTK] Coverage analysis being reported?
In-Reply-To: <CANjZAi8h=-3WhV5EYbVU9e=8UB77GHSAdMO1psLcp+S0i1cEpQ@mail.gmail.com>
References: <CAAKhGh984hZcbSi_5Fa1qcd2h8vSx6184BK-s4tYohZdyOdYcA@mail.gmail.com>
 <CANjZAi8h=-3WhV5EYbVU9e=8UB77GHSAdMO1psLcp+S0i1cEpQ@mail.gmail.com>
Message-ID: <CANjZAi8w0Re5txsHOXzMQQXHB_huQ=54qr3T2W2tRLvsRnP1ig@mail.gmail.com>

Had to update the default gcov to match the gcc version.

If all goes well, that and the remaining valgrind reports should be fixed
tomorrow.

thanks again Jon



David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909 <(518)%20881-4909>

On Mon, Jun 19, 2017 at 8:06 AM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> This and the remaining valgrind defects are correlated with my updating
> gcc on the test machine to meet the c++11 requirement.
> I'll take a closer look this week and figure out what the specific problem
> is.
>
> Thanks for the reminder Jon.
>
> On Jun 19, 2017 2:13 AM, "Jon Haitz Legarreta" <jhlegarreta at vicomtech.org>
> wrote:
>
>> Folks,
>> just a heads-up: is the coverage being reported lately to the dashboard?
>> I had to go back a few weeks (may 22nd) to see the analysis performed by
>> karego.
>>
>> Thanks,
>> JON HAITZ
>>
>>
>> --
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>
> --
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909 <(518)%20881-4909>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170619/67a3a56c/attachment.html>

From jhlegarreta at vicomtech.org  Tue Jun 20 10:04:12 2017
From: jhlegarreta at vicomtech.org (Jon Haitz Legarreta)
Date: Tue, 20 Jun 2017 16:04:12 +0200
Subject: [vtk-developers] [VTK] Coverage analysis being reported?
In-Reply-To: <CANjZAi8w0Re5txsHOXzMQQXHB_huQ=54qr3T2W2tRLvsRnP1ig@mail.gmail.com>
References: <CAAKhGh984hZcbSi_5Fa1qcd2h8vSx6184BK-s4tYohZdyOdYcA@mail.gmail.com>
 <CANjZAi8h=-3WhV5EYbVU9e=8UB77GHSAdMO1psLcp+S0i1cEpQ@mail.gmail.com>
 <CANjZAi8w0Re5txsHOXzMQQXHB_huQ=54qr3T2W2tRLvsRnP1ig@mail.gmail.com>
Message-ID: <CAAKhGh_UKgjy4edXox8hDE4pB-oswmmMFABXV1LtD9Qcp5xNsw@mail.gmail.com>

They're both (dynamic analysis and coverage) back. Thanks Dave.
JON HAITZ

--


On 19 June 2017 at 16:37, David E DeMarle <dave.demarle at kitware.com> wrote:

> Had to update the default gcov to match the gcc version.
>
> If all goes well, that and the remaining valgrind reports should be fixed
> tomorrow.
>
> thanks again Jon
>
>
>
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909 <(518)%20881-4909>
>
> On Mon, Jun 19, 2017 at 8:06 AM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> This and the remaining valgrind defects are correlated with my updating
>> gcc on the test machine to meet the c++11 requirement.
>> I'll take a closer look this week and figure out what the specific
>> problem is.
>>
>> Thanks for the reminder Jon.
>>
>> On Jun 19, 2017 2:13 AM, "Jon Haitz Legarreta" <jhlegarreta at vicomtech.org>
>> wrote:
>>
>>> Folks,
>>> just a heads-up: is the coverage being reported lately to the dashboard?
>>> I had to go back a few weeks (may 22nd) to see the analysis performed by
>>> karego.
>>>
>>> Thanks,
>>> JON HAITZ
>>>
>>>
>>> --
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>
>> --
>> David E DeMarle
>> Kitware, Inc.
>> Principal Engineer
>> 21 Corporate Drive
>> Clifton Park, NY 12065-8662
>> Phone: 518-881-4909 <(518)%20881-4909>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170620/1cc72659/attachment.html>

From robert.maynard at kitware.com  Wed Jun 21 08:29:26 2017
From: robert.maynard at kitware.com (Robert Maynard)
Date: Wed, 21 Jun 2017 08:29:26 -0400
Subject: [vtk-developers] [EXTERNAL] Comparing doubles with floats:
 precision issues
In-Reply-To: <CANwS1=EzpO9vY1q1ymqh25eiOwPOg3nq3DT4rZ-qXAioxdTJjg@mail.gmail.com>
References: <CANwS1=FfXPU9ckJDCrPpd6VvyUcy=djDuFABT2uTyz0AcA-+ZA@mail.gmail.com>
 <5bcd106d1d414b1ea33ce6084e66b84f@ES01AMSNLNT.srn.sandia.gov>
 <CANwS1=EzpO9vY1q1ymqh25eiOwPOg3nq3DT4rZ-qXAioxdTJjg@mail.gmail.com>
Message-ID: <CAFzjYVr2mkMTJ-JbseR9ifUFUgx_06xnZFvgmvqwh4F7r_Geog@mail.gmail.com>

We did something fairly similar to the proposed solution when doing
range computations in the past for ParaView, with the increased
challenge of wanting to move N values in a given direction. I think
that using nextafter will be the best way to get correct results for
your problem though. I would also state that the float -> integer bit
trick is trickier than it looks on the surface and I recommend reading
more on this subject before you dive in (
https://randomascii.wordpress.com/2012/01/23/stupid-float-tricks-2/ ).


On Fri, Jun 16, 2017 at 6:31 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> Hi Alan,
>
> Thanks for the idea, these tricks are always useful to know.  They don't
> solve my issue, though, because my goal isn't just optimization.
>
> The thing is, I already have closed classes that do "if (fval >= fminval &&
> fval <= fmaxval)" where all variables are of type "float".  My problem is,
> that I have a range (minval, maxval) in double-precision, and I have to
> compute (fminval, fminval) in single precision to provide to the existing
> code.  As described above, a naive typecast gives the wrong answer in edge
> cases, which is why fminval = NearestFloatNotGreaterThan(minval) and fmaxval
> = NearestFloatNotLessThan(maxval) are necessary.
>
> Cheers,
>  - David
>
>
> On Fri, Jun 16, 2017 at 3:28 PM, Scott, W Alan <wascott at sandia.gov> wrote:
>>
>> Haven?t seen a great reply, and this was a while ago, but here goes.  This
>> is also all theoretical, from days 20 years ago when I worked on OpenGL
>> drivers.
>>
>>
>>
>> How about the following:
>>
>>
>>
>> test = (minval ? static_cast<double>fval) & (static_cast<double>fval ?
>> maxval)
>>
>>
>>
>> Now, test will be positive if your case should pass, negative if not.  I?m
>> sure I missed some casts above, but you can see what I am doing.  By And?ing
>> the positive bit on the two floats, you see if result is  positive. So,
>> either
>>
>> if(test >= 0)
>>
>>   succeed;
>>
>> else
>>
>>   not so much;
>>
>>
>>
>> Or, if your hardware is faster in integer space (and dirty),
>>
>> if (<unsigned double>test & 0x800000000k)
>>
>>
>>
>> I suspect this whole test should run in under 10 clocks...
>>
>>
>>
>> Be sure to test with different compilers, and especially optimized.
>>
>>
>>
>> Alan
>>
>>
>>
>> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of
>> David Gobbi
>> Sent: Monday, June 12, 2017 12:16 PM
>> To: VTK Developers <vtk-developers at vtk.org>
>> Subject: [EXTERNAL] [vtk-developers] Comparing doubles with floats:
>> precision issues
>>
>>
>>
>> Hi All,
>>
>>
>>
>> This is one of those picky math questions that deals with numerical
>> precision.  Let's say that one has a data set with scalar type "float", and
>> wants to select values within a range (minval, maxval) where minval, maxval
>> are of type "double":
>>
>>
>>
>>     if (fval >= minval && fval <= maxval) { ... }
>>
>>
>>
>> Now let's say you don't want "fval" to be converted to double, because
>> floats are faster than doubles on your hardware:
>>
>>
>>
>>    float fminval = static_cast<float>(minval);
>>
>>    float fmaxval = static_cast<float>(maxval);
>>
>>    ...
>>
>>    if (fval >= fminval && fval <= fmaxval) { ... }
>>
>>
>>
>> Unfortunately, there are some cases where fval <= fmaxval even though fval
>> > maxval.  Reducing the precision of the range has invalidated the check.
>> In order to fix things, you must choose fminval to be the value closest to
>> but not more than minval, and choose fmaxval to be the value closest to but
>> not less than maxval.
>>
>>
>>
>>     float fminval = NearestFloatNotGreaterThan(minval);
>>
>>     float fmaxval = NearestFloatNotLessThan(maxval);
>>
>>
>>
>> With these, (fval >= fminval && fval <= fmaxval) gives the same result as
>> (fval >= minval && val <= fmaxval) and all is right with the world.
>>
>>
>>
>> So my question is, have any other devs created a solution for this issue,
>> either for VTK or for related code?  I'm considering a solution based on the
>> C++11 function std::nextafter(), as described on this stackoverflow page:
>> https://stackoverflow.com/questions/15294046/round-a-double-to-the-closest-and-greater-float
>>
>>
>>
>>  - 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
>
>

From andy.bauer at kitware.com  Wed Jun 21 17:42:19 2017
From: andy.bauer at kitware.com (Andy Bauer)
Date: Wed, 21 Jun 2017 17:42:19 -0400
Subject: [vtk-developers] reading 3D RAW images through vtkImageReader
Message-ID: <CAMaOp+EKz7V4Z_ivQ_+6X3F_D=MmHKV5g2C=ogbJMwN3LeABVg@mail.gmail.com>

Hi,

I'm trying to wrap my head around reading in 3D RAW images through the
vtkImageReader class and am confused about how it's supposed to work when
there are a list of files passed to the reader. I guess the first question
is -- should be able to be done at all?

For a list of 2D RAW images it is required to set the DataExtent in the
third direction to be the number of 2D RAW images (e.g. extent[6] = {0,
xextent, 0, yxtent, 0, numfiles-1}).  If multiple 3D RAW images can be
specified would the extent then look like extent[6] = {0, xextent, 0,
yxtent, 0, (zextent+1)*numfiles-1}) ?

Thanks,
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170621/3b210a9c/attachment.html>

From bill.lorensen at gmail.com  Thu Jun 22 12:24:24 2017
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 22 Jun 2017 12:24:24 -0400
Subject: [vtk-developers] VTK Examples Update
Message-ID: <CADZJ4hPXMeXUVYZBArKOCcM+UNAb0z99gtUERo-zyR-HxGwYuw@mail.gmail.com>

Folks,

The new VTK Examples is looking good.
https://lorensen.github.io/VTKExamples/site/

The last hurdle was the slowness of the mkdocs search. It was not
acceptable, so I added a Google custom search engine with preforms
great.

I registered the site as a google verified site. I also provide a
sitemap to google that helps the indexing.

I plan on removing the Tcl examples since there are so few and we are
not encouraging folks to use Tcl.


And I need to rewrite the Admin page.

Overall the process of moving from the wiki to git has been
interesting. The new site should serve us well into the future.

Bill


-- 
Unpaid intern in BillsBasement at noware dot com

From elvis.stansvik at orexplore.com  Thu Jun 22 12:45:47 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Thu, 22 Jun 2017 18:45:47 +0200
Subject: [vtk-developers] VTK Examples Update
In-Reply-To: <CADZJ4hPXMeXUVYZBArKOCcM+UNAb0z99gtUERo-zyR-HxGwYuw@mail.gmail.com>
References: <CADZJ4hPXMeXUVYZBArKOCcM+UNAb0z99gtUERo-zyR-HxGwYuw@mail.gmail.com>
Message-ID: <CAE-7VJnZHVRFNXbFM=OMP_TXKVW8ipOhWjELgbL1OoZdD2dvNQ@mail.gmail.com>

2017-06-22 18:24 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:

> Folks,
>
> The new VTK Examples is looking good.
> https://lorensen.github.io/VTKExamples/site/
>
> The last hurdle was the slowness of the mkdocs search. It was not
> acceptable, so I added a Google custom search engine with preforms
> great.
>
> I registered the site as a google verified site. I also provide a
> sitemap to google that helps the indexing.
>
> I plan on removing the Tcl examples since there are so few and we are
> not encouraging folks to use Tcl.
>
>
> And I need to rewrite the Admin page.
>
> Overall the process of moving from the wiki to git has been
> interesting. The new site should serve us well into the future.
>

Absolutely, great work Bill! It looks amazing.

This made me think of another (unrelated) question I have regarding the
examples, but I'll make a separate thread about that.

Elvis


> Bill
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
> _______________________________________________
> 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/20170622/a8443249/attachment.html>

From elvis.stansvik at orexplore.com  Thu Jun 22 12:57:24 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Thu, 22 Jun 2017 18:57:24 +0200
Subject: [vtk-developers] vtkNew in examples (or auto?)
Message-ID: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>

Hi all,

How about a refactor of the examples to use vtkNew instead of
vtkSmartPointer (where it makes sense)?

E.g.

  vtkNew<vtkActor> actor;
  actor->SetMapper(mapper);

  vtkNew<vtkRenderer> renderer;
  renderer->AddActor(actor);

instead of

  vtkSmartPointer<vtkActor> actor =
    vtkSmartPointer<vtkActor>::New();
  actor->SetMapper(mapper);

  vtkSmartPointer<vtkRenderer> renderer =
    vtkSmartPointer<vtkRenderer>::New();
  renderer->AddActor(actor);

I think it would help with the readability of the examples. Or are
there other reasons for the prevalent use of vtkSmartPointer?

Another option would be to use auto, e.g.

  auto actor = vtkSmartPointer<vtkActor>::New();

Also, would anyone mind if I did a little naming cleanup, mostly
things like "renwin" -> "window" and "iren" -> "interactor"? Those
abbreviations are not that bad, but I think it's better in examples to
spell out the variables in proper English.

If there are no objections, I could try to prepare an MR when time
permits. If so, vtkNew, or auto?

Elvis

From elvis.stansvik at orexplore.com  Thu Jun 22 12:59:25 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Thu, 22 Jun 2017 18:59:25 +0200
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
Message-ID: <CAE-7VJnfvd8_+QcuYGewpVw1F3rLhTbSNTzBHViPHxF+Fwa2vA@mail.gmail.com>

2017-06-22 18:57 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> Hi all,
>
> How about a refactor of the examples to use vtkNew instead of
> vtkSmartPointer (where it makes sense)?
>
> E.g.
>
>   vtkNew<vtkActor> actor;
>   actor->SetMapper(mapper);
>
>   vtkNew<vtkRenderer> renderer;
>   renderer->AddActor(actor);

Well, missing some .Get() here, but you see what I mean.

Elvis

>
> instead of
>
>   vtkSmartPointer<vtkActor> actor =
>     vtkSmartPointer<vtkActor>::New();
>   actor->SetMapper(mapper);
>
>   vtkSmartPointer<vtkRenderer> renderer =
>     vtkSmartPointer<vtkRenderer>::New();
>   renderer->AddActor(actor);
>
> I think it would help with the readability of the examples. Or are
> there other reasons for the prevalent use of vtkSmartPointer?
>
> Another option would be to use auto, e.g.
>
>   auto actor = vtkSmartPointer<vtkActor>::New();
>
> Also, would anyone mind if I did a little naming cleanup, mostly
> things like "renwin" -> "window" and "iren" -> "interactor"? Those
> abbreviations are not that bad, but I think it's better in examples to
> spell out the variables in proper English.
>
> If there are no objections, I could try to prepare an MR when time
> permits. If so, vtkNew, or auto?
>
> Elvis

From bill.lorensen at gmail.com  Thu Jun 22 13:01:20 2017
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 22 Jun 2017 13:01:20 -0400
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
Message-ID: <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>

I prefer vtkSmartPointer because it can be used like any other vtk
pointer. No need for a GetPointer() is some cases. The example writer
is free to use vtkSmartPointer or vtkNew. But I would leave them as
there are.


Other cleanup's sound great. I've also started using vtkNamedColors
instead of setting float values.

On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
<elvis.stansvik at orexplore.com> wrote:
> Hi all,
>
> How about a refactor of the examples to use vtkNew instead of
> vtkSmartPointer (where it makes sense)?
>
> E.g.
>
>   vtkNew<vtkActor> actor;
>   actor->SetMapper(mapper);
>
>   vtkNew<vtkRenderer> renderer;
>   renderer->AddActor(actor);
>
> instead of
>
>   vtkSmartPointer<vtkActor> actor =
>     vtkSmartPointer<vtkActor>::New();
>   actor->SetMapper(mapper);
>
>   vtkSmartPointer<vtkRenderer> renderer =
>     vtkSmartPointer<vtkRenderer>::New();
>   renderer->AddActor(actor);
>
> I think it would help with the readability of the examples. Or are
> there other reasons for the prevalent use of vtkSmartPointer?
>
> Another option would be to use auto, e.g.
>
>   auto actor = vtkSmartPointer<vtkActor>::New();
>
> Also, would anyone mind if I did a little naming cleanup, mostly
> things like "renwin" -> "window" and "iren" -> "interactor"? Those
> abbreviations are not that bad, but I think it's better in examples to
> spell out the variables in proper English.
>
> If there are no objections, I could try to prepare an MR when time
> permits. If so, vtkNew, or auto?
>
> Elvis
> _______________________________________________
> 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
>



-- 
Unpaid intern in BillsBasement at noware dot com

From elvis.stansvik at orexplore.com  Thu Jun 22 13:07:51 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Thu, 22 Jun 2017 19:07:51 +0200
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
Message-ID: <CAE-7VJ=02XVq9ZskD=0Zvp8Pv4iTc6T2XEdZS6M4vPd+BUX+aQ@mail.gmail.com>

2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
> I prefer vtkSmartPointer because it can be used like any other vtk
> pointer. No need for a GetPointer() is some cases. The example writer
> is free to use vtkSmartPointer or vtkNew. But I would leave them as
> there are.

Right, that's a valid point. But how about auto-fying the
declarations? (but keep using vtkSmartPointer)

My motivation is that when reading an example, I'm often squinting to
find the variable names in the declarations, wedged in there somewhere
between all those type names and angle brackets. Especially as the
lines are often broken due to running long.

>
>
> Other cleanup's sound great. I've also started using vtkNamedColors
> instead of setting float values.

Great.

Elvis

>
> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
>> Hi all,
>>
>> How about a refactor of the examples to use vtkNew instead of
>> vtkSmartPointer (where it makes sense)?
>>
>> E.g.
>>
>>   vtkNew<vtkActor> actor;
>>   actor->SetMapper(mapper);
>>
>>   vtkNew<vtkRenderer> renderer;
>>   renderer->AddActor(actor);
>>
>> instead of
>>
>>   vtkSmartPointer<vtkActor> actor =
>>     vtkSmartPointer<vtkActor>::New();
>>   actor->SetMapper(mapper);
>>
>>   vtkSmartPointer<vtkRenderer> renderer =
>>     vtkSmartPointer<vtkRenderer>::New();
>>   renderer->AddActor(actor);
>>
>> I think it would help with the readability of the examples. Or are
>> there other reasons for the prevalent use of vtkSmartPointer?
>>
>> Another option would be to use auto, e.g.
>>
>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>
>> Also, would anyone mind if I did a little naming cleanup, mostly
>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>> abbreviations are not that bad, but I think it's better in examples to
>> spell out the variables in proper English.
>>
>> If there are no objections, I could try to prepare an MR when time
>> permits. If so, vtkNew, or auto?
>>
>> Elvis
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com

From bill.lorensen at gmail.com  Thu Jun 22 13:09:07 2017
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 22 Jun 2017 13:09:07 -0400
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CAE-7VJ=02XVq9ZskD=0Zvp8Pv4iTc6T2XEdZS6M4vPd+BUX+aQ@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
 <CAE-7VJ=02XVq9ZskD=0Zvp8Pv4iTc6T2XEdZS6M4vPd+BUX+aQ@mail.gmail.com>
Message-ID: <CADZJ4hNbZCW9WQ=xZov49UC2V0C0M80i6rkHRim9fxY2MORS3Q@mail.gmail.com>

I'm not sure what you mean by auto-fying



On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
<elvis.stansvik at orexplore.com> wrote:
> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>> I prefer vtkSmartPointer because it can be used like any other vtk
>> pointer. No need for a GetPointer() is some cases. The example writer
>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
>> there are.
>
> Right, that's a valid point. But how about auto-fying the
> declarations? (but keep using vtkSmartPointer)
>
> My motivation is that when reading an example, I'm often squinting to
> find the variable names in the declarations, wedged in there somewhere
> between all those type names and angle brackets. Especially as the
> lines are often broken due to running long.
>
>>
>>
>> Other cleanup's sound great. I've also started using vtkNamedColors
>> instead of setting float values.
>
> Great.
>
> Elvis
>
>>
>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>> <elvis.stansvik at orexplore.com> wrote:
>>> Hi all,
>>>
>>> How about a refactor of the examples to use vtkNew instead of
>>> vtkSmartPointer (where it makes sense)?
>>>
>>> E.g.
>>>
>>>   vtkNew<vtkActor> actor;
>>>   actor->SetMapper(mapper);
>>>
>>>   vtkNew<vtkRenderer> renderer;
>>>   renderer->AddActor(actor);
>>>
>>> instead of
>>>
>>>   vtkSmartPointer<vtkActor> actor =
>>>     vtkSmartPointer<vtkActor>::New();
>>>   actor->SetMapper(mapper);
>>>
>>>   vtkSmartPointer<vtkRenderer> renderer =
>>>     vtkSmartPointer<vtkRenderer>::New();
>>>   renderer->AddActor(actor);
>>>
>>> I think it would help with the readability of the examples. Or are
>>> there other reasons for the prevalent use of vtkSmartPointer?
>>>
>>> Another option would be to use auto, e.g.
>>>
>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>>
>>> Also, would anyone mind if I did a little naming cleanup, mostly
>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>>> abbreviations are not that bad, but I think it's better in examples to
>>> spell out the variables in proper English.
>>>
>>> If there are no objections, I could try to prepare an MR when time
>>> permits. If so, vtkNew, or auto?
>>>
>>> Elvis
>>> _______________________________________________
>>> 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
>>>
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com

From elvis.stansvik at orexplore.com  Thu Jun 22 13:13:47 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Thu, 22 Jun 2017 19:13:47 +0200
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CADZJ4hNbZCW9WQ=xZov49UC2V0C0M80i6rkHRim9fxY2MORS3Q@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
 <CAE-7VJ=02XVq9ZskD=0Zvp8Pv4iTc6T2XEdZS6M4vPd+BUX+aQ@mail.gmail.com>
 <CADZJ4hNbZCW9WQ=xZov49UC2V0C0M80i6rkHRim9fxY2MORS3Q@mail.gmail.com>
Message-ID: <CAE-7VJmUkwr22uEATp-MUx9HCQhs0kHa77vggEFOiLzwjKN=Kw@mail.gmail.com>

2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
> I'm not sure what you mean by auto-fying

Sorry, I should have been clearer. What I mean is changing declarations such as

  vtkSmartPointer<vtkActor> actor =
    vtkSmartPointer<vtkActor>::New();

into

  auto actor = vtkSmartPointer<vtkActor>::New();

I think it would cut down on the number of lines in many examples, and
make them more readable. (This would only be done in places where the
type of the variable is still clear from the declaration.)

Elvis

>
>
>
> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>> I prefer vtkSmartPointer because it can be used like any other vtk
>>> pointer. No need for a GetPointer() is some cases. The example writer
>>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
>>> there are.
>>
>> Right, that's a valid point. But how about auto-fying the
>> declarations? (but keep using vtkSmartPointer)
>>
>> My motivation is that when reading an example, I'm often squinting to
>> find the variable names in the declarations, wedged in there somewhere
>> between all those type names and angle brackets. Especially as the
>> lines are often broken due to running long.
>>
>>>
>>>
>>> Other cleanup's sound great. I've also started using vtkNamedColors
>>> instead of setting float values.
>>
>> Great.
>>
>> Elvis
>>
>>>
>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>>> <elvis.stansvik at orexplore.com> wrote:
>>>> Hi all,
>>>>
>>>> How about a refactor of the examples to use vtkNew instead of
>>>> vtkSmartPointer (where it makes sense)?
>>>>
>>>> E.g.
>>>>
>>>>   vtkNew<vtkActor> actor;
>>>>   actor->SetMapper(mapper);
>>>>
>>>>   vtkNew<vtkRenderer> renderer;
>>>>   renderer->AddActor(actor);
>>>>
>>>> instead of
>>>>
>>>>   vtkSmartPointer<vtkActor> actor =
>>>>     vtkSmartPointer<vtkActor>::New();
>>>>   actor->SetMapper(mapper);
>>>>
>>>>   vtkSmartPointer<vtkRenderer> renderer =
>>>>     vtkSmartPointer<vtkRenderer>::New();
>>>>   renderer->AddActor(actor);
>>>>
>>>> I think it would help with the readability of the examples. Or are
>>>> there other reasons for the prevalent use of vtkSmartPointer?
>>>>
>>>> Another option would be to use auto, e.g.
>>>>
>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>
>>>> Also, would anyone mind if I did a little naming cleanup, mostly
>>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>>>> abbreviations are not that bad, but I think it's better in examples to
>>>> spell out the variables in proper English.
>>>>
>>>> If there are no objections, I could try to prepare an MR when time
>>>> permits. If so, vtkNew, or auto?
>>>>
>>>> Elvis
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com

From bill.lorensen at gmail.com  Thu Jun 22 13:32:55 2017
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 22 Jun 2017 13:32:55 -0400
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CAE-7VJmUkwr22uEATp-MUx9HCQhs0kHa77vggEFOiLzwjKN=Kw@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
 <CAE-7VJ=02XVq9ZskD=0Zvp8Pv4iTc6T2XEdZS6M4vPd+BUX+aQ@mail.gmail.com>
 <CADZJ4hNbZCW9WQ=xZov49UC2V0C0M80i6rkHRim9fxY2MORS3Q@mail.gmail.com>
 <CAE-7VJmUkwr22uEATp-MUx9HCQhs0kHa77vggEFOiLzwjKN=Kw@mail.gmail.com>
Message-ID: <CADZJ4hP47ypDcSJTjx5DvUNssQCEKkC52j0D=V-iFmXziOtU8g@mail.gmail.com>

Let's leave them as is for now. I want to make sure I understand this.


On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
<elvis.stansvik at orexplore.com> wrote:
> 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>> I'm not sure what you mean by auto-fying
>
> Sorry, I should have been clearer. What I mean is changing declarations such as
>
>   vtkSmartPointer<vtkActor> actor =
>     vtkSmartPointer<vtkActor>::New();
>
> into
>
>   auto actor = vtkSmartPointer<vtkActor>::New();
>
> I think it would cut down on the number of lines in many examples, and
> make them more readable. (This would only be done in places where the
> type of the variable is still clear from the declaration.)
>
> Elvis
>
>>
>>
>>
>> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
>> <elvis.stansvik at orexplore.com> wrote:
>>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>> I prefer vtkSmartPointer because it can be used like any other vtk
>>>> pointer. No need for a GetPointer() is some cases. The example writer
>>>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
>>>> there are.
>>>
>>> Right, that's a valid point. But how about auto-fying the
>>> declarations? (but keep using vtkSmartPointer)
>>>
>>> My motivation is that when reading an example, I'm often squinting to
>>> find the variable names in the declarations, wedged in there somewhere
>>> between all those type names and angle brackets. Especially as the
>>> lines are often broken due to running long.
>>>
>>>>
>>>>
>>>> Other cleanup's sound great. I've also started using vtkNamedColors
>>>> instead of setting float values.
>>>
>>> Great.
>>>
>>> Elvis
>>>
>>>>
>>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>> Hi all,
>>>>>
>>>>> How about a refactor of the examples to use vtkNew instead of
>>>>> vtkSmartPointer (where it makes sense)?
>>>>>
>>>>> E.g.
>>>>>
>>>>>   vtkNew<vtkActor> actor;
>>>>>   actor->SetMapper(mapper);
>>>>>
>>>>>   vtkNew<vtkRenderer> renderer;
>>>>>   renderer->AddActor(actor);
>>>>>
>>>>> instead of
>>>>>
>>>>>   vtkSmartPointer<vtkActor> actor =
>>>>>     vtkSmartPointer<vtkActor>::New();
>>>>>   actor->SetMapper(mapper);
>>>>>
>>>>>   vtkSmartPointer<vtkRenderer> renderer =
>>>>>     vtkSmartPointer<vtkRenderer>::New();
>>>>>   renderer->AddActor(actor);
>>>>>
>>>>> I think it would help with the readability of the examples. Or are
>>>>> there other reasons for the prevalent use of vtkSmartPointer?
>>>>>
>>>>> Another option would be to use auto, e.g.
>>>>>
>>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>
>>>>> Also, would anyone mind if I did a little naming cleanup, mostly
>>>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>>>>> abbreviations are not that bad, but I think it's better in examples to
>>>>> spell out the variables in proper English.
>>>>>
>>>>> If there are no objections, I could try to prepare an MR when time
>>>>> permits. If so, vtkNew, or auto?
>>>>>
>>>>> Elvis
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Unpaid intern in BillsBasement at noware dot com
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com

From elvis.stansvik at orexplore.com  Thu Jun 22 13:44:54 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Thu, 22 Jun 2017 19:44:54 +0200
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CADZJ4hP47ypDcSJTjx5DvUNssQCEKkC52j0D=V-iFmXziOtU8g@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
 <CAE-7VJ=02XVq9ZskD=0Zvp8Pv4iTc6T2XEdZS6M4vPd+BUX+aQ@mail.gmail.com>
 <CADZJ4hNbZCW9WQ=xZov49UC2V0C0M80i6rkHRim9fxY2MORS3Q@mail.gmail.com>
 <CAE-7VJmUkwr22uEATp-MUx9HCQhs0kHa77vggEFOiLzwjKN=Kw@mail.gmail.com>
 <CADZJ4hP47ypDcSJTjx5DvUNssQCEKkC52j0D=V-iFmXziOtU8g@mail.gmail.com>
Message-ID: <CAE-7VJniPMp_GrD5dFZsUXOxL0nCmFfFAAOZC0+nTBG-cHaX5w@mail.gmail.com>

2017-06-22 19:32 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
> Let's leave them as is for now. I want to make sure I understand this.

Alright, fair enough, it's not a big gripe. Just let me know if you
change your mind in the future and I can do the work.

Elvis

>
>
> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
>> 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>> I'm not sure what you mean by auto-fying
>>
>> Sorry, I should have been clearer. What I mean is changing declarations such as
>>
>>   vtkSmartPointer<vtkActor> actor =
>>     vtkSmartPointer<vtkActor>::New();
>>
>> into
>>
>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>
>> I think it would cut down on the number of lines in many examples, and
>> make them more readable. (This would only be done in places where the
>> type of the variable is still clear from the declaration.)
>>
>> Elvis
>>
>>>
>>>
>>>
>>> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
>>> <elvis.stansvik at orexplore.com> wrote:
>>>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>> I prefer vtkSmartPointer because it can be used like any other vtk
>>>>> pointer. No need for a GetPointer() is some cases. The example writer
>>>>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
>>>>> there are.
>>>>
>>>> Right, that's a valid point. But how about auto-fying the
>>>> declarations? (but keep using vtkSmartPointer)
>>>>
>>>> My motivation is that when reading an example, I'm often squinting to
>>>> find the variable names in the declarations, wedged in there somewhere
>>>> between all those type names and angle brackets. Especially as the
>>>> lines are often broken due to running long.
>>>>
>>>>>
>>>>>
>>>>> Other cleanup's sound great. I've also started using vtkNamedColors
>>>>> instead of setting float values.
>>>>
>>>> Great.
>>>>
>>>> Elvis
>>>>
>>>>>
>>>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> How about a refactor of the examples to use vtkNew instead of
>>>>>> vtkSmartPointer (where it makes sense)?
>>>>>>
>>>>>> E.g.
>>>>>>
>>>>>>   vtkNew<vtkActor> actor;
>>>>>>   actor->SetMapper(mapper);
>>>>>>
>>>>>>   vtkNew<vtkRenderer> renderer;
>>>>>>   renderer->AddActor(actor);
>>>>>>
>>>>>> instead of
>>>>>>
>>>>>>   vtkSmartPointer<vtkActor> actor =
>>>>>>     vtkSmartPointer<vtkActor>::New();
>>>>>>   actor->SetMapper(mapper);
>>>>>>
>>>>>>   vtkSmartPointer<vtkRenderer> renderer =
>>>>>>     vtkSmartPointer<vtkRenderer>::New();
>>>>>>   renderer->AddActor(actor);
>>>>>>
>>>>>> I think it would help with the readability of the examples. Or are
>>>>>> there other reasons for the prevalent use of vtkSmartPointer?
>>>>>>
>>>>>> Another option would be to use auto, e.g.
>>>>>>
>>>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>>
>>>>>> Also, would anyone mind if I did a little naming cleanup, mostly
>>>>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>>>>>> abbreviations are not that bad, but I think it's better in examples to
>>>>>> spell out the variables in proper English.
>>>>>>
>>>>>> If there are no objections, I could try to prepare an MR when time
>>>>>> permits. If so, vtkNew, or auto?
>>>>>>
>>>>>> Elvis
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com

From ricardo_morello at hotmail.com  Thu Jun 22 14:21:31 2017
From: ricardo_morello at hotmail.com (Ricardo)
Date: Thu, 22 Jun 2017 11:21:31 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
Message-ID: <1498155691150-5743731.post@n5.nabble.com>

 I've been trying to use VTK with OpenVR on an HTC Vive Glass, and I am
facing some problems I can't seem to solve. First of all, I'm using Visual
Studio 2015 x64 on a Windows 10 machine with VTK 7.1.1, following the
instructions at
https://blog.kitware.com/using-virtual-reality-devices-with-vtk/. When
trying to compile an example on VS
(http://www.vtk.org/Wiki/VTK/Examples/Cxx/GeometricObjects/Cylinder) the
volume seems to be preetty normal when seen from my monitor. However, when
seen from the vive glasses, the cylinder does not appear, and in it's place
there is only a dark image.
VTK was built using VS 2015 with both  the Module_VTKRenderingOpenVR and
VTK_OPENVR_OBJECT_FACTORY checked.
Thanks for the help!




--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From ricardo_morello at hotmail.com  Thu Jun 22 14:34:42 2017
From: ricardo_morello at hotmail.com (Ricardo)
Date: Thu, 22 Jun 2017 11:34:42 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <1498155691150-5743731.post@n5.nabble.com>
References: <1498155691150-5743731.post@n5.nabble.com>
Message-ID: <1498156482678-5743732.post@n5.nabble.com>

Update: Forgot to mention that I replaced Renderer, RenderWindow and
RenderWindowInteractor with its respective OpenVRClasses in the example. 
Here's a picture of what is going on in the glasses:
<http://vtk.1045678.n5.nabble.com/file/n5743732/f95e5225-bf14-47e9-af3c-a4c95a6258bb.jpg> 
And in my screen:
<http://vtk.1045678.n5.nabble.com/file/n5743732/Capturar.png> 
Thanks!



--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731p5743732.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From rcourant at gmail.com  Thu Jun 22 14:57:14 2017
From: rcourant at gmail.com (Carlos Lopez)
Date: Thu, 22 Jun 2017 14:57:14 -0400
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <1498156482678-5743732.post@n5.nabble.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
Message-ID: <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>

Hello,

when creating objects for HTC, keep in mind that the space is in meters, so
the cylinder in the example is 7 meters tall and 10 meters wide. You'll
most likely be looking at it from the inside.
(also, the Y axis is up)

The blue lines inside the head mounted display probably come from the blue
circle that the HTC compositor places, so it seems to me there may be an
issue with the tracking. Is the demo room app working correctly for you?

--carlos

(sorry for the double message)

On Thu, Jun 22, 2017 at 2:34 PM, Ricardo <ricardo_morello at hotmail.com>
wrote:

> Update: Forgot to mention that I replaced Renderer, RenderWindow and
> RenderWindowInteractor with its respective OpenVRClasses in the example.
> Here's a picture of what is going on in the glasses:
> <http://vtk.1045678.n5.nabble.com/file/n5743732/f95e5225-
> bf14-47e9-af3c-a4c95a6258bb.jpg>
> And in my screen:
> <http://vtk.1045678.n5.nabble.com/file/n5743732/Capturar.png>
> Thanks!
>
>
>
> --
> View this message in context: http://vtk.1045678.n5.nabble.
> com/OpenVR-HTC-Vive-tp5743731p5743732.html
> Sent from the VTK - Dev mailing list archive at Nabble.com.
> _______________________________________________
> 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/20170622/af53eef4/attachment-0001.html>

From ricardo_morello at hotmail.com  Thu Jun 22 15:31:05 2017
From: ricardo_morello at hotmail.com (Ricardo)
Date: Thu, 22 Jun 2017 12:31:05 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
 <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
Message-ID: <1498159865720-5743734.post@n5.nabble.com>

Carlos, thanks for the answer!
I also forgot to mention that i reduced the cylinder's radius and height to
0.1, so it should not be inside the cylinder. I adjusted the tracking and
now there are no more blue lines, just the blue circle the HTC compositor
places. However, the cylinder is still not rendering in the scene. Here is
the example with OpenVR classes:

#include "stdafx.h"
#include <vtkCylinderSource.h>
#include <vtkPolyData.h>
#include <vtkSmartPointer.h>
#include <vtkPolyDataMapper.h>
#include <vtkActor.h>
#include <vtkOpenVRRenderWindow.h>
#include <vtkOpenVRRenderer.h>
#include <vtkOpenVRRenderWindowInteractor.h>
#include <vtkOpenVRCamera.h>
#include "vtkAutoInit.h" 
VTK_MODULE_INIT(vtkRenderingOpenGL2); 
VTK_MODULE_INIT(vtkInteractionStyle);

int main(int, char *argv[])
{
	// Create a sphere
	vtkSmartPointer<vtkCylinderSource> cylinderSource =
		vtkSmartPointer<vtkCylinderSource>::New();
	cylinderSource->SetCenter(0.0, 0.0, 0.0);
	cylinderSource->SetRadius(0.1);
	cylinderSource->SetHeight(0.1);
	cylinderSource->SetResolution(100);

	// Create a mapper and actor
	vtkSmartPointer<vtkPolyDataMapper> mapper =
		vtkSmartPointer<vtkPolyDataMapper>::New();
	mapper->SetInputConnection(cylinderSource->GetOutputPort());
	vtkSmartPointer<vtkActor> actor =
		vtkSmartPointer<vtkActor>::New();
	actor->SetMapper(mapper);


        vtkSmartPointer< vtkOpenVRCamera > camera = 
                vtkSmartPointer<vtkOpenVRCamera>::New();

	//Create a renderer, render window, and interactor
	vtkSmartPointer<vtkOpenVRRenderer> renderer =
		vtkSmartPointer<vtkOpenVRRenderer>::New();

	renderer->SetActiveCamera(camera);

	vtkSmartPointer<vtkOpenVRRenderWindow> renderWindow =
		vtkSmartPointer<vtkOpenVRRenderWindow>::New();
	renderWindow->AddRenderer(renderer);
	vtkSmartPointer<vtkOpenVRRenderWindowInteractor> renderWindowInteractor =
		vtkSmartPointer<vtkOpenVRRenderWindowInteractor>::New();
	renderWindowInteractor->SetRenderWindow(renderWindow);

	// Add the actor to the scene
	renderer->AddActor(actor);
	renderer->SetBackground(.1, .3, .2); // Background color dark green

										 // Render and interact
	renderWindow->SetWindowName(argv[0]);
	renderWindow->Render();
	renderWindowInteractor->Start();

	return EXIT_SUCCESS;
}
The demo room app works normally, so there might be a mistake with the code
or the VS configuration, I'm not sure

Thanks!



--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731p5743734.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From rcourant at gmail.com  Thu Jun 22 18:25:57 2017
From: rcourant at gmail.com (Carlos Lopez)
Date: Thu, 22 Jun 2017 18:25:57 -0400
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <1498159865720-5743734.post@n5.nabble.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
 <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
 <1498159865720-5743734.post@n5.nabble.com>
Message-ID: <CAL=Mvsp=Mo2gfULdrdgoucpzytTgRgGXefOp7ik=c2QkXMfJrQ@mail.gmail.com>

There are 2 factory options (at least) in VTK's cmake. With both of them
active, the example you mentioned (http://www.vtk.org/Wiki/VTK/Examples/Cxx/
GeometricObjects/Cylinder) works for me by only replacing the renderer,
render window and interactor classes with their openVR counterparts.



On Thu, Jun 22, 2017 at 3:31 PM, Ricardo <ricardo_morello at hotmail.com>
wrote:

> Carlos, thanks for the answer!
> I also forgot to mention that i reduced the cylinder's radius and height to
> 0.1, so it should not be inside the cylinder. I adjusted the tracking and
> now there are no more blue lines, just the blue circle the HTC compositor
> places. However, the cylinder is still not rendering in the scene. Here is
> the example with OpenVR classes:
>
> #include "stdafx.h"
> #include <vtkCylinderSource.h>
> #include <vtkPolyData.h>
> #include <vtkSmartPointer.h>
> #include <vtkPolyDataMapper.h>
> #include <vtkActor.h>
> #include <vtkOpenVRRenderWindow.h>
> #include <vtkOpenVRRenderer.h>
> #include <vtkOpenVRRenderWindowInteractor.h>
> #include <vtkOpenVRCamera.h>
> #include "vtkAutoInit.h"
> VTK_MODULE_INIT(vtkRenderingOpenGL2);
> VTK_MODULE_INIT(vtkInteractionStyle);
>
> int main(int, char *argv[])
> {
>         // Create a sphere
>         vtkSmartPointer<vtkCylinderSource> cylinderSource =
>                 vtkSmartPointer<vtkCylinderSource>::New();
>         cylinderSource->SetCenter(0.0, 0.0, 0.0);
>         cylinderSource->SetRadius(0.1);
>         cylinderSource->SetHeight(0.1);
>         cylinderSource->SetResolution(100);
>
>         // Create a mapper and actor
>         vtkSmartPointer<vtkPolyDataMapper> mapper =
>                 vtkSmartPointer<vtkPolyDataMapper>::New();
>         mapper->SetInputConnection(cylinderSource->GetOutputPort());
>         vtkSmartPointer<vtkActor> actor =
>                 vtkSmartPointer<vtkActor>::New();
>         actor->SetMapper(mapper);
>
>
>         vtkSmartPointer< vtkOpenVRCamera > camera =
>                 vtkSmartPointer<vtkOpenVRCamera>::New();
>
>         //Create a renderer, render window, and interactor
>         vtkSmartPointer<vtkOpenVRRenderer> renderer =
>                 vtkSmartPointer<vtkOpenVRRenderer>::New();
>
>         renderer->SetActiveCamera(camera);
>
>         vtkSmartPointer<vtkOpenVRRenderWindow> renderWindow =
>                 vtkSmartPointer<vtkOpenVRRenderWindow>::New();
>         renderWindow->AddRenderer(renderer);
>         vtkSmartPointer<vtkOpenVRRenderWindowInteractor>
> renderWindowInteractor =
>                 vtkSmartPointer<vtkOpenVRRenderWindowInteractor>::New();
>         renderWindowInteractor->SetRenderWindow(renderWindow);
>
>         // Add the actor to the scene
>         renderer->AddActor(actor);
>         renderer->SetBackground(.1, .3, .2); // Background color dark green
>
>
>        // Render and interact
>         renderWindow->SetWindowName(argv[0]);
>         renderWindow->Render();
>         renderWindowInteractor->Start();
>
>         return EXIT_SUCCESS;
> }
> The demo room app works normally, so there might be a mistake with the code
> or the VS configuration, I'm not sure
>
> Thanks!
>
>
>
> --
> View this message in context: http://vtk.1045678.n5.nabble.
> com/OpenVR-HTC-Vive-tp5743731p5743734.html
> Sent from the VTK - Dev mailing list archive at Nabble.com.
> _______________________________________________
> 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/20170622/21b0aa6f/attachment.html>

From ricardo_morello at hotmail.com  Thu Jun 22 18:44:32 2017
From: ricardo_morello at hotmail.com (Ricardo)
Date: Thu, 22 Jun 2017 15:44:32 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <CAL=Mvsp=Mo2gfULdrdgoucpzytTgRgGXefOp7ik=c2QkXMfJrQ@mail.gmail.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
 <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
 <1498159865720-5743734.post@n5.nabble.com>
 <CAL=Mvsp=Mo2gfULdrdgoucpzytTgRgGXefOp7ik=c2QkXMfJrQ@mail.gmail.com>
Message-ID: <1498171472336-5743737.post@n5.nabble.com>

So you've built VTK 7.1.1 with both these options checked? Maybe I've
configured something wrong... Are you using Visual Studio? if so, which
version? 
These are my steps:
I downloaded VTK's latest release (7.1.1), compiled it with cmake with the
following options:

<http://vtk.1045678.n5.nabble.com/file/n5743737/Capturar.png> 

Then I generated the solution file through CMake and builded it's solution
with VS.
CMake asked for some additional libraries such as openvr SDK which i
downloaded and compiled following the link I sent earlier. The SDL library
came in openvr's folder.
Then, I created a project in VS and configured the additional include and
library directories, as well as the additional dependencies. 
What I can't understand is how the image in my computer is different from
the vive glasses. Do you have any idea of what could be causing this to
happen? Am I using an incorrect version of sdl or openvr? I can't find any
mistakes in the code I sent, so I guess it might be a library configuration
mistake, although I am not sure in which step of the configuration process
I've committed this mistake. 

Thanks for the answer once again!
Hope to hear from you soon,
Ricardo




--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731p5743737.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From andrew.amaclean at gmail.com  Thu Jun 22 19:21:01 2017
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Fri, 23 Jun 2017 09:21:01 +1000
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
Message-ID: <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>

Hi Bill, Elvis,
   Elvis, personally I wouldn't like to see the homogenisation of the
examples by doing what you propose.
The reasons are:
1) One of the advantages of the examples is seeing the different approaches
used by the contributors.
2) It may dissuade contributors by implicitly forcing them to use a
particular approach.
3) One of the really useful things in the example is the different ways VTK
is used.

To me it matters little whether:
auto actor = vtkSmartPointer<vtkActor>::New();
?
vtkSmartPointer<vtkActor> actor =
    vtkSmartPointer<vtkActor>::New();

or whether "ren/renWin" is used instead of "renderer" or "rendererWindow"
in the examples.

Of more importance are explanatory notes in the examples.

Bill, I see you are using vtkNamedColors. This example shows what other
things you can do with this class:
https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/NamedColors/

For example, assign colors by name:
renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetData
());
Create your own named color (in this case a red with an alpha of 0.5):
namedColors->GetColor("Red", rgba);
rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);

Regards
   Andrew


> ---------- Forwarded message ----------
> From: Bill Lorensen <bill.lorensen at gmail.com>
> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
> Cc: vtkdev <vtk-developers at vtk.org>
> Bcc:
> Date: Thu, 22 Jun 2017 13:32:55 -0400
> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
> Let's leave them as is for now. I want to make sure I understand this.
>
>
> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
> > 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
> >> I'm not sure what you mean by auto-fying
> >
> > Sorry, I should have been clearer. What I mean is changing declarations
> such as
> >
> >
> ??
> vtkSmartPointer<vtkActor> actor =
> >     vtkSmartPointer<vtkActor>::New();
> >
> > into
> >
> >   auto actor = vtkSmartPointer<vtkActor>::New();
> >
> > I think it would cut down on the number of lines in many examples, and
> > make them more readable. (This would only be done in places where the
> > type of the variable is still clear from the declaration.)
> >
> > Elvis
> >
> >>
> >>
> >>
> >> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
> >> <elvis.stansvik at orexplore.com> wrote:
> >>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
> >>>> I prefer vtkSmartPointer because it can be used like any other vtk
> >>>> pointer. No need for a GetPointer() is some cases. The example writer
> >>>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
> >>>> there are.
> >>>
> >>> Right, that's a valid point. But how about auto-fying the
> >>> declarations? (but keep using vtkSmartPointer)
> >>>
> >>> My motivation is that when reading an example, I'm often squinting to
> >>> find the variable names in the declarations, wedged in there somewhere
> >>> between all those type names and angle brackets. Especially as the
> >>> lines are often broken due to running long.
> >>>
> >>>>
> >>>>
> >>>> Other cleanup's sound great. I've also started using vtkNamedColors
> >>>> instead of setting float values.
> >>>
> >>> Great.
> >>>
> >>> Elvis
> >>>
> >>>>
> >>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
> >>>> <elvis.stansvik at orexplore.com> wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> How about a refactor of the examples to use vtkNew instead of
> >>>>> vtkSmartPointer (where it makes sense)?
> >>>>>
> >>>>> E.g.
> >>>>>
> >>>>>   vtkNew<vtkActor> actor;
> >>>>>   actor->SetMapper(mapper);
> >>>>>
> >>>>>   vtkNew<vtkRenderer> renderer;
> >>>>>   renderer->AddActor(actor);
> >>>>>
> >>>>> instead of
> >>>>>
> >>>>>   vtkSmartPointer<vtkActor> actor =
> >>>>>     vtkSmartPointer<vtkActor>::New();
> >>>>>   actor->SetMapper(mapper);
> >>>>>
> >>>>>   vtkSmartPointer<vtkRenderer> renderer =
> >>>>>     vtkSmartPointer<vtkRenderer>::New();
> >>>>>   renderer->AddActor(actor);
> >>>>>
> >>>>> I think it would help with the readability of the examples. Or are
> >>>>> there other reasons for the prevalent use of vtkSmartPointer?
> >>>>>
> >>>>> Another option would be to use auto, e.g.
> >>>>>
> >>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
> >>>>>
> >>>>> Also, would anyone mind if I did a little naming cleanup, mostly
> >>>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
> >>>>> abbreviations are not that bad, but I think it's better in examples
> to
> >>>>> spell out the variables in proper English.
> >>>>>
> >>>>> If there are no objections, I could try to prepare an MR when time
> >>>>> permits. If so, vtkNew, or auto?
> >>>>>
> >>>>> Elvis
> >>>>> _______________________________________________
> >>>>> 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
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Unpaid intern in BillsBasement at noware dot com
> >>
> >>
> >>
> >> --
> >> Unpaid intern in BillsBasement at noware dot com
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com
>
>

-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170623/deaf447b/attachment-0001.html>

From ricardo_morello at hotmail.com  Thu Jun 22 22:55:01 2017
From: ricardo_morello at hotmail.com (Ricardo)
Date: Thu, 22 Jun 2017 19:55:01 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <1498171472336-5743737.post@n5.nabble.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
 <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
 <1498159865720-5743734.post@n5.nabble.com>
 <CAL=Mvsp=Mo2gfULdrdgoucpzytTgRgGXefOp7ik=c2QkXMfJrQ@mail.gmail.com>
 <1498171472336-5743737.post@n5.nabble.com>
Message-ID: <1498186501910-5743740.post@n5.nabble.com>

It works! The problem was not with the configuration process, but with my
notebook drivers. Updated my video driver and it is now working 100%. Thanks
for the help!




--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731p5743740.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From elvis.stansvik at orexplore.com  Fri Jun 23 04:29:11 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 23 Jun 2017 10:29:11 +0200
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
Message-ID: <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>

2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
> Hi Bill, Elvis,
>    Elvis, personally I wouldn't like to see the homogenisation of the
> examples by doing what you propose.
> The reasons are:
> 1) One of the advantages of the examples is seeing the different approaches
> used by the contributors.
> 2) It may dissuade contributors by implicitly forcing them to use a
> particular approach.
> 3) One of the really useful things in the example is the different ways VTK
> is used.

I absolutely agree with 1 and 3 (which I think are the same?), but I
don't see how changing to auto would in affect anything in this
regard.

I also don't see how it would be a homogenization. The declarations I
would change are already homogeneous in that they're all
vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New(). Changing to auto
would not make it more or less homogeneous.

It would be aNote that this is not about changing vtkNew to vtkSmartPointer.

And how would changing to auto in any way affect the approach taken by
the example?



> To me it matters little whether:
> auto actor = vtkSmartPointer<vtkActor>::New();
> vtkSmartPointer<vtkActor> actor =
>     vtkSmartPointer<vtkActor>::New();
>
> or whether "ren/renWin" is used instead of "renderer" or "rendererWindow" in
> the examples.
>
> Of more importance are explanatory notes in the examples.
>
> Bill, I see you are using vtkNamedColors. This example shows what other
> things you can do with this class:
> https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/NamedColors/
>
> For example, assign colors by name:
> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetData
> ());
> Create your own named color (in this case a red with an alpha of 0.5):
> namedColors->GetColor("Red", rgba);
> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>
> Regards
>    Andrew
>
>>
>> ---------- Forwarded message ----------
>> From: Bill Lorensen <bill.lorensen at gmail.com>
>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>> Cc: vtkdev <vtk-developers at vtk.org>
>> Bcc:
>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
>> Let's leave them as is for now. I want to make sure I understand this.
>>
>>
>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
>> <elvis.stansvik at orexplore.com> wrote:
>> > 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>> >> I'm not sure what you mean by auto-fying
>> >
>> > Sorry, I should have been clearer. What I mean is changing declarations
>> > such as
>> >
>> >
>> vtkSmartPointer<vtkActor> actor =
>> >     vtkSmartPointer<vtkActor>::New();
>> >
>> > into
>> >
>> >   auto actor = vtkSmartPointer<vtkActor>::New();
>> >
>> > I think it would cut down on the number of lines in many examples, and
>> > make them more readable. (This would only be done in places where the
>> > type of the variable is still clear from the declaration.)
>> >
>> > Elvis
>> >
>> >>
>> >>
>> >>
>> >> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
>> >> <elvis.stansvik at orexplore.com> wrote:
>> >>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>> >>>> I prefer vtkSmartPointer because it can be used like any other vtk
>> >>>> pointer. No need for a GetPointer() is some cases. The example writer
>> >>>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
>> >>>> there are.
>> >>>
>> >>> Right, that's a valid point. But how about auto-fying the
>> >>> declarations? (but keep using vtkSmartPointer)
>> >>>
>> >>> My motivation is that when reading an example, I'm often squinting to
>> >>> find the variable names in the declarations, wedged in there somewhere
>> >>> between all those type names and angle brackets. Especially as the
>> >>> lines are often broken due to running long.
>> >>>
>> >>>>
>> >>>>
>> >>>> Other cleanup's sound great. I've also started using vtkNamedColors
>> >>>> instead of setting float values.
>> >>>
>> >>> Great.
>> >>>
>> >>> Elvis
>> >>>
>> >>>>
>> >>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>> >>>> <elvis.stansvik at orexplore.com> wrote:
>> >>>>> Hi all,
>> >>>>>
>> >>>>> How about a refactor of the examples to use vtkNew instead of
>> >>>>> vtkSmartPointer (where it makes sense)?
>> >>>>>
>> >>>>> E.g.
>> >>>>>
>> >>>>>   vtkNew<vtkActor> actor;
>> >>>>>   actor->SetMapper(mapper);
>> >>>>>
>> >>>>>   vtkNew<vtkRenderer> renderer;
>> >>>>>   renderer->AddActor(actor);
>> >>>>>
>> >>>>> instead of
>> >>>>>
>> >>>>>   vtkSmartPointer<vtkActor> actor =
>> >>>>>     vtkSmartPointer<vtkActor>::New();
>> >>>>>   actor->SetMapper(mapper);
>> >>>>>
>> >>>>>   vtkSmartPointer<vtkRenderer> renderer =
>> >>>>>     vtkSmartPointer<vtkRenderer>::New();
>> >>>>>   renderer->AddActor(actor);
>> >>>>>
>> >>>>> I think it would help with the readability of the examples. Or are
>> >>>>> there other reasons for the prevalent use of vtkSmartPointer?
>> >>>>>
>> >>>>> Another option would be to use auto, e.g.
>> >>>>>
>> >>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>> >>>>>
>> >>>>> Also, would anyone mind if I did a little naming cleanup, mostly
>> >>>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>> >>>>> abbreviations are not that bad, but I think it's better in examples
>> >>>>> to
>> >>>>> spell out the variables in proper English.
>> >>>>>
>> >>>>> If there are no objections, I could try to prepare an MR when time
>> >>>>> permits. If so, vtkNew, or auto?
>> >>>>>
>> >>>>> Elvis
>> >>>>> _______________________________________________
>> >>>>> 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
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Unpaid intern in BillsBasement at noware dot com
>> >>
>> >>
>> >>
>> >> --
>> >> Unpaid intern in BillsBasement at noware dot com
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>>
>
>
> --
> ___________________________________________
> Andrew J. P. Maclean
>
> ___________________________________________

From elvis.stansvik at orexplore.com  Fri Jun 23 04:33:48 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 23 Jun 2017 10:33:48 +0200
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
Message-ID: <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>

Sorry, accidently hit send. Fixes below.

2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>> Hi Bill, Elvis,
>>    Elvis, personally I wouldn't like to see the homogenisation of the
>> examples by doing what you propose.
>> The reasons are:
>> 1) One of the advantages of the examples is seeing the different approaches
>> used by the contributors.
>> 2) It may dissuade contributors by implicitly forcing them to use a
>> particular approach.
>> 3) One of the really useful things in the example is the different ways VTK
>> is used.
>
> I absolutely agree with 1 and 3 (which I think are the same?), but I
> don't see how changing to auto would in affect anything in this
> regard.
>
> I also don't see how it would be a homogenization. The declarations I
> would change are already homogeneous in that they're all
> vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New(). Changing to auto
> would not make it more or less homogeneous.
>
> It would be a

... It would be homogenisation if I'd change all
vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's not
what this is about.

> Note that this is not about changing vtkNew to vtkSmartPointer.
>
> And how would changing to auto in any way affect the approach taken by
> the example?
>
>
>
>> To me it matters little whether:
>> auto actor = vtkSmartPointer<vtkActor>::New();
>> vtkSmartPointer<vtkActor> actor =
>>     vtkSmartPointer<vtkActor>::New();
>>
>> or whether "ren/renWin" is used instead of "renderer" or "rendererWindow" in
>> the examples.

It matters little to me too, but it does matter. I think it's almost
indisputable that

    auto someVar = vtkSmartPointer<SomeLongTypeName>::New()

is more readable than

    vtkSmartPointer<SomeLongTypeName> someVar =
        vtkSmartPointer<SomeLongTypeName>::New();

especially since the latter leads to many more lines to scan across
when looking for something in the examples.

So, in short I agree with everything you say, but I can't see how
changing one way of doing declarations to another is a homogenization.
And I do think spelling matters.

I'm perfectly OK with leaving the examples exactly like they are
though, just wanted to explain how I see it.

Elvis

>>
>> Of more importance are explanatory notes in the examples.
>>
>> Bill, I see you are using vtkNamedColors. This example shows what other
>> things you can do with this class:
>> https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/NamedColors/
>>
>> For example, assign colors by name:
>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetData
>> ());
>> Create your own named color (in this case a red with an alpha of 0.5):
>> namedColors->GetColor("Red", rgba);
>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>
>> Regards
>>    Andrew
>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>> Cc: vtkdev <vtk-developers at vtk.org>
>>> Bcc:
>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
>>> Let's leave them as is for now. I want to make sure I understand this.
>>>
>>>
>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
>>> <elvis.stansvik at orexplore.com> wrote:
>>> > 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>> >> I'm not sure what you mean by auto-fying
>>> >
>>> > Sorry, I should have been clearer. What I mean is changing declarations
>>> > such as
>>> >
>>> >
>>> vtkSmartPointer<vtkActor> actor =
>>> >     vtkSmartPointer<vtkActor>::New();
>>> >
>>> > into
>>> >
>>> >   auto actor = vtkSmartPointer<vtkActor>::New();
>>> >
>>> > I think it would cut down on the number of lines in many examples, and
>>> > make them more readable. (This would only be done in places where the
>>> > type of the variable is still clear from the declaration.)
>>> >
>>> > Elvis
>>> >
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
>>> >> <elvis.stansvik at orexplore.com> wrote:
>>> >>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>> >>>> I prefer vtkSmartPointer because it can be used like any other vtk
>>> >>>> pointer. No need for a GetPointer() is some cases. The example writer
>>> >>>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
>>> >>>> there are.
>>> >>>
>>> >>> Right, that's a valid point. But how about auto-fying the
>>> >>> declarations? (but keep using vtkSmartPointer)
>>> >>>
>>> >>> My motivation is that when reading an example, I'm often squinting to
>>> >>> find the variable names in the declarations, wedged in there somewhere
>>> >>> between all those type names and angle brackets. Especially as the
>>> >>> lines are often broken due to running long.
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> Other cleanup's sound great. I've also started using vtkNamedColors
>>> >>>> instead of setting float values.
>>> >>>
>>> >>> Great.
>>> >>>
>>> >>> Elvis
>>> >>>
>>> >>>>
>>> >>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>>> >>>> <elvis.stansvik at orexplore.com> wrote:
>>> >>>>> Hi all,
>>> >>>>>
>>> >>>>> How about a refactor of the examples to use vtkNew instead of
>>> >>>>> vtkSmartPointer (where it makes sense)?
>>> >>>>>
>>> >>>>> E.g.
>>> >>>>>
>>> >>>>>   vtkNew<vtkActor> actor;
>>> >>>>>   actor->SetMapper(mapper);
>>> >>>>>
>>> >>>>>   vtkNew<vtkRenderer> renderer;
>>> >>>>>   renderer->AddActor(actor);
>>> >>>>>
>>> >>>>> instead of
>>> >>>>>
>>> >>>>>   vtkSmartPointer<vtkActor> actor =
>>> >>>>>     vtkSmartPointer<vtkActor>::New();
>>> >>>>>   actor->SetMapper(mapper);
>>> >>>>>
>>> >>>>>   vtkSmartPointer<vtkRenderer> renderer =
>>> >>>>>     vtkSmartPointer<vtkRenderer>::New();
>>> >>>>>   renderer->AddActor(actor);
>>> >>>>>
>>> >>>>> I think it would help with the readability of the examples. Or are
>>> >>>>> there other reasons for the prevalent use of vtkSmartPointer?
>>> >>>>>
>>> >>>>> Another option would be to use auto, e.g.
>>> >>>>>
>>> >>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>> >>>>>
>>> >>>>> Also, would anyone mind if I did a little naming cleanup, mostly
>>> >>>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>>> >>>>> abbreviations are not that bad, but I think it's better in examples
>>> >>>>> to
>>> >>>>> spell out the variables in proper English.
>>> >>>>>
>>> >>>>> If there are no objections, I could try to prepare an MR when time
>>> >>>>> permits. If so, vtkNew, or auto?
>>> >>>>>
>>> >>>>> Elvis
>>> >>>>> _______________________________________________
>>> >>>>> 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
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Unpaid intern in BillsBasement at noware dot com
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Unpaid intern in BillsBasement at noware dot com
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>
>>
>> --
>> ___________________________________________
>> Andrew J. P. Maclean
>>
>> ___________________________________________

From elvis.stansvik at orexplore.com  Fri Jun 23 04:47:20 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 23 Jun 2017 10:47:20 +0200
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
Message-ID: <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>

2017-06-23 10:33 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> Sorry, accidently hit send. Fixes below.
>
> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>>> Hi Bill, Elvis,
>>>    Elvis, personally I wouldn't like to see the homogenisation of the
>>> examples by doing what you propose.
>>> The reasons are:
>>> 1) One of the advantages of the examples is seeing the different approaches
>>> used by the contributors.
>>> 2) It may dissuade contributors by implicitly forcing them to use a
>>> particular approach.
>>> 3) One of the really useful things in the example is the different ways VTK
>>> is used.
>>
>> I absolutely agree with 1 and 3 (which I think are the same?), but I
>> don't see how changing to auto would in affect anything in this
>> regard.
>>
>> I also don't see how it would be a homogenization. The declarations I
>> would change are already homogeneous in that they're all
>> vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New(). Changing to auto
>> would not make it more or less homogeneous.
>>
>> It would be a
>
> ... It would be homogenisation if I'd change all
> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's not
> what this is about.
>
>> Note that this is not about changing vtkNew to vtkSmartPointer.
>>
>> And how would changing to auto in any way affect the approach taken by
>> the example?
>>
>>
>>
>>> To me it matters little whether:
>>> auto actor = vtkSmartPointer<vtkActor>::New();
>>> vtkSmartPointer<vtkActor> actor =
>>>     vtkSmartPointer<vtkActor>::New();
>>>
>>> or whether "ren/renWin" is used instead of "renderer" or "rendererWindow" in
>>> the examples.
>
> It matters little to me too, but it does matter. I think it's almost
> indisputable that
>
>     auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
>
> is more readable than
>
>     vtkSmartPointer<SomeLongTypeName> someVar =
>         vtkSmartPointer<SomeLongTypeName>::New();
>
> especially since the latter leads to many more lines to scan across
> when looking for something in the examples.

Another small plus I see with using auto is it's a keyword which would
be highlighted, so the declarations would stand out more.

E.g. looking at the code for this example

    https://lorensen.github.io/VTKExamples/site/Cxx/Filtering/ConnectivityFilter/

I find it hard to quickly answer "what are the declarations?", since
they have no highlighting compared to the surrounding statements. Had
they been auto, it would have been easier since I think auto would
have been highlighted.

I think quickly identifying the variables involved helps the reading
of the examples.

Elvis

>
> So, in short I agree with everything you say, but I can't see how
> changing one way of doing declarations to another is a homogenization.
> And I do think spelling matters.
>
> I'm perfectly OK with leaving the examples exactly like they are
> though, just wanted to explain how I see it.
>
> Elvis
>
>>>
>>> Of more importance are explanatory notes in the examples.
>>>
>>> Bill, I see you are using vtkNamedColors. This example shows what other
>>> things you can do with this class:
>>> https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/NamedColors/
>>>
>>> For example, assign colors by name:
>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetData
>>> ());
>>> Create your own named color (in this case a red with an alpha of 0.5):
>>> namedColors->GetColor("Red", rgba);
>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>>
>>> Regards
>>>    Andrew
>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>> Cc: vtkdev <vtk-developers at vtk.org>
>>>> Bcc:
>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
>>>> Let's leave them as is for now. I want to make sure I understand this.
>>>>
>>>>
>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
>>>> <elvis.stansvik at orexplore.com> wrote:
>>>> > 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>> >> I'm not sure what you mean by auto-fying
>>>> >
>>>> > Sorry, I should have been clearer. What I mean is changing declarations
>>>> > such as
>>>> >
>>>> >
>>>> vtkSmartPointer<vtkActor> actor =
>>>> >     vtkSmartPointer<vtkActor>::New();
>>>> >
>>>> > into
>>>> >
>>>> >   auto actor = vtkSmartPointer<vtkActor>::New();
>>>> >
>>>> > I think it would cut down on the number of lines in many examples, and
>>>> > make them more readable. (This would only be done in places where the
>>>> > type of the variable is still clear from the declaration.)
>>>> >
>>>> > Elvis
>>>> >
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
>>>> >> <elvis.stansvik at orexplore.com> wrote:
>>>> >>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>> >>>> I prefer vtkSmartPointer because it can be used like any other vtk
>>>> >>>> pointer. No need for a GetPointer() is some cases. The example writer
>>>> >>>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
>>>> >>>> there are.
>>>> >>>
>>>> >>> Right, that's a valid point. But how about auto-fying the
>>>> >>> declarations? (but keep using vtkSmartPointer)
>>>> >>>
>>>> >>> My motivation is that when reading an example, I'm often squinting to
>>>> >>> find the variable names in the declarations, wedged in there somewhere
>>>> >>> between all those type names and angle brackets. Especially as the
>>>> >>> lines are often broken due to running long.
>>>> >>>
>>>> >>>>
>>>> >>>>
>>>> >>>> Other cleanup's sound great. I've also started using vtkNamedColors
>>>> >>>> instead of setting float values.
>>>> >>>
>>>> >>> Great.
>>>> >>>
>>>> >>> Elvis
>>>> >>>
>>>> >>>>
>>>> >>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>>>> >>>> <elvis.stansvik at orexplore.com> wrote:
>>>> >>>>> Hi all,
>>>> >>>>>
>>>> >>>>> How about a refactor of the examples to use vtkNew instead of
>>>> >>>>> vtkSmartPointer (where it makes sense)?
>>>> >>>>>
>>>> >>>>> E.g.
>>>> >>>>>
>>>> >>>>>   vtkNew<vtkActor> actor;
>>>> >>>>>   actor->SetMapper(mapper);
>>>> >>>>>
>>>> >>>>>   vtkNew<vtkRenderer> renderer;
>>>> >>>>>   renderer->AddActor(actor);
>>>> >>>>>
>>>> >>>>> instead of
>>>> >>>>>
>>>> >>>>>   vtkSmartPointer<vtkActor> actor =
>>>> >>>>>     vtkSmartPointer<vtkActor>::New();
>>>> >>>>>   actor->SetMapper(mapper);
>>>> >>>>>
>>>> >>>>>   vtkSmartPointer<vtkRenderer> renderer =
>>>> >>>>>     vtkSmartPointer<vtkRenderer>::New();
>>>> >>>>>   renderer->AddActor(actor);
>>>> >>>>>
>>>> >>>>> I think it would help with the readability of the examples. Or are
>>>> >>>>> there other reasons for the prevalent use of vtkSmartPointer?
>>>> >>>>>
>>>> >>>>> Another option would be to use auto, e.g.
>>>> >>>>>
>>>> >>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>>> >>>>>
>>>> >>>>> Also, would anyone mind if I did a little naming cleanup, mostly
>>>> >>>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>>>> >>>>> abbreviations are not that bad, but I think it's better in examples
>>>> >>>>> to
>>>> >>>>> spell out the variables in proper English.
>>>> >>>>>
>>>> >>>>> If there are no objections, I could try to prepare an MR when time
>>>> >>>>> permits. If so, vtkNew, or auto?
>>>> >>>>>
>>>> >>>>> Elvis
>>>> >>>>> _______________________________________________
>>>> >>>>> 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
>>>> >>>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>> Unpaid intern in BillsBasement at noware dot com
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Unpaid intern in BillsBasement at noware dot com
>>>>
>>>>
>>>>
>>>> --
>>>> Unpaid intern in BillsBasement at noware dot com
>>>>
>>>
>>>
>>> --
>>> ___________________________________________
>>> Andrew J. P. Maclean
>>>
>>> ___________________________________________

From DLRdave at aol.com  Fri Jun 23 05:29:39 2017
From: DLRdave at aol.com (David Cole)
Date: Fri, 23 Jun 2017 05:29:39 -0400
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
Message-ID: <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>

One thing I would point out is some folks who might want to compile
the VTK examples may be using a slightly older version of VTK, and
perhaps one that is not even being compiled with a modern compiler
capable of compiling C++ 11...

So I would refrain from using "auto" in the examples until such time
as all the people who want to build an example are pretty much
guaranteed to be using a VTK which requires C++ 11, and therefore a
compiler capable of dealing with C++ 11 constructs.

I wouldn't do the "auto" thing just yet.


David C.



On Fri, Jun 23, 2017 at 4:47 AM, Elvis Stansvik
<elvis.stansvik at orexplore.com> wrote:
> 2017-06-23 10:33 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>> Sorry, accidently hit send. Fixes below.
>>
>> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>>>> Hi Bill, Elvis,
>>>>    Elvis, personally I wouldn't like to see the homogenisation of the
>>>> examples by doing what you propose.
>>>> The reasons are:
>>>> 1) One of the advantages of the examples is seeing the different approaches
>>>> used by the contributors.
>>>> 2) It may dissuade contributors by implicitly forcing them to use a
>>>> particular approach.
>>>> 3) One of the really useful things in the example is the different ways VTK
>>>> is used.
>>>
>>> I absolutely agree with 1 and 3 (which I think are the same?), but I
>>> don't see how changing to auto would in affect anything in this
>>> regard.
>>>
>>> I also don't see how it would be a homogenization. The declarations I
>>> would change are already homogeneous in that they're all
>>> vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New(). Changing to auto
>>> would not make it more or less homogeneous.
>>>
>>> It would be a
>>
>> ... It would be homogenisation if I'd change all
>> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's not
>> what this is about.
>>
>>> Note that this is not about changing vtkNew to vtkSmartPointer.
>>>
>>> And how would changing to auto in any way affect the approach taken by
>>> the example?
>>>
>>>
>>>
>>>> To me it matters little whether:
>>>> auto actor = vtkSmartPointer<vtkActor>::New();
>>>> vtkSmartPointer<vtkActor> actor =
>>>>     vtkSmartPointer<vtkActor>::New();
>>>>
>>>> or whether "ren/renWin" is used instead of "renderer" or "rendererWindow" in
>>>> the examples.
>>
>> It matters little to me too, but it does matter. I think it's almost
>> indisputable that
>>
>>     auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
>>
>> is more readable than
>>
>>     vtkSmartPointer<SomeLongTypeName> someVar =
>>         vtkSmartPointer<SomeLongTypeName>::New();
>>
>> especially since the latter leads to many more lines to scan across
>> when looking for something in the examples.
>
> Another small plus I see with using auto is it's a keyword which would
> be highlighted, so the declarations would stand out more.
>
> E.g. looking at the code for this example
>
>     https://lorensen.github.io/VTKExamples/site/Cxx/Filtering/ConnectivityFilter/
>
> I find it hard to quickly answer "what are the declarations?", since
> they have no highlighting compared to the surrounding statements. Had
> they been auto, it would have been easier since I think auto would
> have been highlighted.
>
> I think quickly identifying the variables involved helps the reading
> of the examples.
>
> Elvis
>
>>
>> So, in short I agree with everything you say, but I can't see how
>> changing one way of doing declarations to another is a homogenization.
>> And I do think spelling matters.
>>
>> I'm perfectly OK with leaving the examples exactly like they are
>> though, just wanted to explain how I see it.
>>
>> Elvis
>>
>>>>
>>>> Of more importance are explanatory notes in the examples.
>>>>
>>>> Bill, I see you are using vtkNamedColors. This example shows what other
>>>> things you can do with this class:
>>>> https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/NamedColors/
>>>>
>>>> For example, assign colors by name:
>>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetData
>>>> ());
>>>> Create your own named color (in this case a red with an alpha of 0.5):
>>>> namedColors->GetColor("Red", rgba);
>>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>>>
>>>> Regards
>>>>    Andrew
>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>>> Cc: vtkdev <vtk-developers at vtk.org>
>>>>> Bcc:
>>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
>>>>> Let's leave them as is for now. I want to make sure I understand this.
>>>>>
>>>>>
>>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>> > 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>> >> I'm not sure what you mean by auto-fying
>>>>> >
>>>>> > Sorry, I should have been clearer. What I mean is changing declarations
>>>>> > such as
>>>>> >
>>>>> >
>>>>> vtkSmartPointer<vtkActor> actor =
>>>>> >     vtkSmartPointer<vtkActor>::New();
>>>>> >
>>>>> > into
>>>>> >
>>>>> >   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>> >
>>>>> > I think it would cut down on the number of lines in many examples, and
>>>>> > make them more readable. (This would only be done in places where the
>>>>> > type of the variable is still clear from the declaration.)
>>>>> >
>>>>> > Elvis
>>>>> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
>>>>> >> <elvis.stansvik at orexplore.com> wrote:
>>>>> >>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>> >>>> I prefer vtkSmartPointer because it can be used like any other vtk
>>>>> >>>> pointer. No need for a GetPointer() is some cases. The example writer
>>>>> >>>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
>>>>> >>>> there are.
>>>>> >>>
>>>>> >>> Right, that's a valid point. But how about auto-fying the
>>>>> >>> declarations? (but keep using vtkSmartPointer)
>>>>> >>>
>>>>> >>> My motivation is that when reading an example, I'm often squinting to
>>>>> >>> find the variable names in the declarations, wedged in there somewhere
>>>>> >>> between all those type names and angle brackets. Especially as the
>>>>> >>> lines are often broken due to running long.
>>>>> >>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Other cleanup's sound great. I've also started using vtkNamedColors
>>>>> >>>> instead of setting float values.
>>>>> >>>
>>>>> >>> Great.
>>>>> >>>
>>>>> >>> Elvis
>>>>> >>>
>>>>> >>>>
>>>>> >>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>>>>> >>>> <elvis.stansvik at orexplore.com> wrote:
>>>>> >>>>> Hi all,
>>>>> >>>>>
>>>>> >>>>> How about a refactor of the examples to use vtkNew instead of
>>>>> >>>>> vtkSmartPointer (where it makes sense)?
>>>>> >>>>>
>>>>> >>>>> E.g.
>>>>> >>>>>
>>>>> >>>>>   vtkNew<vtkActor> actor;
>>>>> >>>>>   actor->SetMapper(mapper);
>>>>> >>>>>
>>>>> >>>>>   vtkNew<vtkRenderer> renderer;
>>>>> >>>>>   renderer->AddActor(actor);
>>>>> >>>>>
>>>>> >>>>> instead of
>>>>> >>>>>
>>>>> >>>>>   vtkSmartPointer<vtkActor> actor =
>>>>> >>>>>     vtkSmartPointer<vtkActor>::New();
>>>>> >>>>>   actor->SetMapper(mapper);
>>>>> >>>>>
>>>>> >>>>>   vtkSmartPointer<vtkRenderer> renderer =
>>>>> >>>>>     vtkSmartPointer<vtkRenderer>::New();
>>>>> >>>>>   renderer->AddActor(actor);
>>>>> >>>>>
>>>>> >>>>> I think it would help with the readability of the examples. Or are
>>>>> >>>>> there other reasons for the prevalent use of vtkSmartPointer?
>>>>> >>>>>
>>>>> >>>>> Another option would be to use auto, e.g.
>>>>> >>>>>
>>>>> >>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>> >>>>>
>>>>> >>>>> Also, would anyone mind if I did a little naming cleanup, mostly
>>>>> >>>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>>>>> >>>>> abbreviations are not that bad, but I think it's better in examples
>>>>> >>>>> to
>>>>> >>>>> spell out the variables in proper English.
>>>>> >>>>>
>>>>> >>>>> If there are no objections, I could try to prepare an MR when time
>>>>> >>>>> permits. If so, vtkNew, or auto?
>>>>> >>>>>
>>>>> >>>>> Elvis
>>>>> >>>>> _______________________________________________
>>>>> >>>>> 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
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> Unpaid intern in BillsBasement at noware dot com
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Unpaid intern in BillsBasement at noware dot com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>
>>>>
>>>>
>>>> --
>>>> ___________________________________________
>>>> Andrew J. P. Maclean
>>>>
>>>> ___________________________________________
> _______________________________________________
> 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
>

From lasso at queensu.ca  Fri Jun 23 07:04:19 2017
From: lasso at queensu.ca (Andras Lasso)
Date: Fri, 23 Jun 2017 11:04:19 +0000
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>,
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
Message-ID: <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>

I find vtkNew<?> to be the shortest and most readable way of creating a new VTK object. However, it is rather inconvenient that GetPointer() must be called to get the pointer. Is there a specific reason for requiring using GetPointer()? Could we change vtkNew to have automatic conversion to pointer type - the same way as in vtkSmartPointer?



Andras



From: David Cole via vtk-developers<mailto:vtk-developers at vtk.org>
Sent: Friday, June 23, 2017 5:29 AM
To: Elvis Stansvik<mailto:elvis.stansvik at orexplore.com>
Cc: VTK Developers<mailto:vtk-developers at vtk.org>; Andrew Maclean<mailto:andrew.amaclean at gmail.com>
Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21



One thing I would point out is some folks who might want to compile
the VTK examples may be using a slightly older version of VTK, and
perhaps one that is not even being compiled with a modern compiler
capable of compiling C++ 11...

So I would refrain from using "auto" in the examples until such time
as all the people who want to build an example are pretty much
guaranteed to be using a VTK which requires C++ 11, and therefore a
compiler capable of dealing with C++ 11 constructs.

I wouldn't do the "auto" thing just yet.


David C.



On Fri, Jun 23, 2017 at 4:47 AM, Elvis Stansvik
<elvis.stansvik at orexplore.com> wrote:
> 2017-06-23 10:33 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>> Sorry, accidently hit send. Fixes below.
>>
>> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>>>> Hi Bill, Elvis,
>>>>    Elvis, personally I wouldn't like to see the homogenisation of the
>>>> examples by doing what you propose.
>>>> The reasons are:
>>>> 1) One of the advantages of the examples is seeing the different approaches
>>>> used by the contributors.
>>>> 2) It may dissuade contributors by implicitly forcing them to use a
>>>> particular approach.
>>>> 3) One of the really useful things in the example is the different ways VTK
>>>> is used.
>>>
>>> I absolutely agree with 1 and 3 (which I think are the same?), but I
>>> don't see how changing to auto would in affect anything in this
>>> regard.
>>>
>>> I also don't see how it would be a homogenization. The declarations I
>>> would change are already homogeneous in that they're all
>>> vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New(). Changing to auto
>>> would not make it more or less homogeneous.
>>>
>>> It would be a
>>
>> ... It would be homogenisation if I'd change all
>> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's not
>> what this is about.
>>
>>> Note that this is not about changing vtkNew to vtkSmartPointer.
>>>
>>> And how would changing to auto in any way affect the approach taken by
>>> the example?
>>>
>>>
>>>
>>>> To me it matters little whether:
>>>> auto actor = vtkSmartPointer<vtkActor>::New();
>>>> vtkSmartPointer<vtkActor> actor =
>>>>     vtkSmartPointer<vtkActor>::New();
>>>>
>>>> or whether "ren/renWin" is used instead of "renderer" or "rendererWindow" in
>>>> the examples.
>>
>> It matters little to me too, but it does matter. I think it's almost
>> indisputable that
>>
>>     auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
>>
>> is more readable than
>>
>>     vtkSmartPointer<SomeLongTypeName> someVar =
>>         vtkSmartPointer<SomeLongTypeName>::New();
>>
>> especially since the latter leads to many more lines to scan across
>> when looking for something in the examples.
>
> Another small plus I see with using auto is it's a keyword which would
> be highlighted, so the declarations would stand out more.
>
> E.g. looking at the code for this example
>
>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Florensen.github.io%2FVTKExamples%2Fsite%2FCxx%2FFiltering%2FConnectivityFilter%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=ha%2BCR8CriMPmQqz%2FxrAgI6lQ7RKn21tuZ6Z%2FitzKD%2Fg%3D&reserved=0
>
> I find it hard to quickly answer "what are the declarations?", since
> they have no highlighting compared to the surrounding statements. Had
> they been auto, it would have been easier since I think auto would
> have been highlighted.
>
> I think quickly identifying the variables involved helps the reading
> of the examples.
>
> Elvis
>
>>
>> So, in short I agree with everything you say, but I can't see how
>> changing one way of doing declarations to another is a homogenization.
>> And I do think spelling matters.
>>
>> I'm perfectly OK with leaving the examples exactly like they are
>> though, just wanted to explain how I see it.
>>
>> Elvis
>>
>>>>
>>>> Of more importance are explanatory notes in the examples.
>>>>
>>>> Bill, I see you are using vtkNamedColors. This example shows what other
>>>> things you can do with this class:
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Florensen.github.io%2FVTKExamples%2Fsite%2FCxx%2FVisualization%2FNamedColors%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=jnbJJe87OvOErNapbQL2HiAt6DnbOWifp67W4lNVqfo%3D&reserved=0
>>>>
>>>> For example, assign colors by name:
>>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetData
>>>> ());
>>>> Create your own named color (in this case a red with an alpha of 0.5):
>>>> namedColors->GetColor("Red", rgba);
>>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>>>
>>>> Regards
>>>>    Andrew
>>>>
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>>> Cc: vtkdev <vtk-developers at vtk.org>
>>>>> Bcc:
>>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
>>>>> Let's leave them as is for now. I want to make sure I understand this.
>>>>>
>>>>>
>>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>> > 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>> >> I'm not sure what you mean by auto-fying
>>>>> >
>>>>> > Sorry, I should have been clearer. What I mean is changing declarations
>>>>> > such as
>>>>> >
>>>>> >
>>>>> vtkSmartPointer<vtkActor> actor =
>>>>> >     vtkSmartPointer<vtkActor>::New();
>>>>> >
>>>>> > into
>>>>> >
>>>>> >   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>> >
>>>>> > I think it would cut down on the number of lines in many examples, and
>>>>> > make them more readable. (This would only be done in places where the
>>>>> > type of the variable is still clear from the declaration.)
>>>>> >
>>>>> > Elvis
>>>>> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
>>>>> >> <elvis.stansvik at orexplore.com> wrote:
>>>>> >>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>> >>>> I prefer vtkSmartPointer because it can be used like any other vtk
>>>>> >>>> pointer. No need for a GetPointer() is some cases. The example writer
>>>>> >>>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
>>>>> >>>> there are.
>>>>> >>>
>>>>> >>> Right, that's a valid point. But how about auto-fying the
>>>>> >>> declarations? (but keep using vtkSmartPointer)
>>>>> >>>
>>>>> >>> My motivation is that when reading an example, I'm often squinting to
>>>>> >>> find the variable names in the declarations, wedged in there somewhere
>>>>> >>> between all those type names and angle brackets. Especially as the
>>>>> >>> lines are often broken due to running long.
>>>>> >>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Other cleanup's sound great. I've also started using vtkNamedColors
>>>>> >>>> instead of setting float values.
>>>>> >>>
>>>>> >>> Great.
>>>>> >>>
>>>>> >>> Elvis
>>>>> >>>
>>>>> >>>>
>>>>> >>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>>>>> >>>> <elvis.stansvik at orexplore.com> wrote:
>>>>> >>>>> Hi all,
>>>>> >>>>>
>>>>> >>>>> How about a refactor of the examples to use vtkNew instead of
>>>>> >>>>> vtkSmartPointer (where it makes sense)?
>>>>> >>>>>
>>>>> >>>>> E.g.
>>>>> >>>>>
>>>>> >>>>>   vtkNew<vtkActor> actor;
>>>>> >>>>>   actor->SetMapper(mapper);
>>>>> >>>>>
>>>>> >>>>>   vtkNew<vtkRenderer> renderer;
>>>>> >>>>>   renderer->AddActor(actor);
>>>>> >>>>>
>>>>> >>>>> instead of
>>>>> >>>>>
>>>>> >>>>>   vtkSmartPointer<vtkActor> actor =
>>>>> >>>>>     vtkSmartPointer<vtkActor>::New();
>>>>> >>>>>   actor->SetMapper(mapper);
>>>>> >>>>>
>>>>> >>>>>   vtkSmartPointer<vtkRenderer> renderer =
>>>>> >>>>>     vtkSmartPointer<vtkRenderer>::New();
>>>>> >>>>>   renderer->AddActor(actor);
>>>>> >>>>>
>>>>> >>>>> I think it would help with the readability of the examples. Or are
>>>>> >>>>> there other reasons for the prevalent use of vtkSmartPointer?
>>>>> >>>>>
>>>>> >>>>> Another option would be to use auto, e.g.
>>>>> >>>>>
>>>>> >>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>> >>>>>
>>>>> >>>>> Also, would anyone mind if I did a little naming cleanup, mostly
>>>>> >>>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>>>>> >>>>> abbreviations are not that bad, but I think it's better in examples
>>>>> >>>>> to
>>>>> >>>>> spell out the variables in proper English.
>>>>> >>>>>
>>>>> >>>>> If there are no objections, I could try to prepare an MR when time
>>>>> >>>>> permits. If so, vtkNew, or auto?
>>>>> >>>>>
>>>>> >>>>> Elvis
>>>>> >>>>> _______________________________________________
>>>>> >>>>> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>>>>> >>>>>
>>>>> >>>>> Visit other Kitware open-source projects at
>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
>>>>> >>>>>
>>>>> >>>>> Search the list archives at:
>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3OZk%3D&reserved=0
>>>>> >>>>>
>>>>> >>>>> Follow this link to subscribe/unsubscribe:
>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> Unpaid intern in BillsBasement at noware dot com
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Unpaid intern in BillsBasement at noware dot com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>
>>>>
>>>>
>>>> --
>>>> ___________________________________________
>>>> Andrew J. P. Maclean
>>>>
>>>> ___________________________________________
> _______________________________________________
> Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>
> Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
>
> Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3OZk%3D&reserved=0
>
> Follow this link to subscribe/unsubscribe:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>
_______________________________________________
Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0

Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOVfY%3D&reserved=0

Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3OZk%3D&reserved=0

Follow this link to subscribe/unsubscribe:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170623/091e6f96/attachment-0001.html>

From DLRdave at aol.com  Fri Jun 23 07:24:19 2017
From: DLRdave at aol.com (David Cole)
Date: Fri, 23 Jun 2017 07:24:19 -0400
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
Message-ID: <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>

The reason for not allowing automatic conversion to pointer with
vtkNew is to prevent people from returning a stale/dead pointer from a
method.

It would be disastrous to allow automatic conversion to a raw pointer.
The intent is to make it easy to create a local variable that goes
away automatically when the scope closes. Allowing conversion to a raw
pointer would make it very easy to write bad code.

It's safe to return a vtkSmartPointer from a method, and use the
GetPointer from a vtkNew to do so, but not a raw pointer, unless you
have some guarantee that some other reference to the pointer is
keeping it alive.


HTH,
David C.




On Fri, Jun 23, 2017 at 7:04 AM, Andras Lasso <lasso at queensu.ca> wrote:
> I find vtkNew<?> to be the shortest and most readable way of creating a new
> VTK object. However, it is rather inconvenient that GetPointer() must be
> called to get the pointer. Is there a specific reason for requiring using
> GetPointer()? Could we change vtkNew to have automatic conversion to pointer
> type - the same way as in vtkSmartPointer?
>
>
>
> Andras
>
>
>
> From: David Cole via vtk-developers
> Sent: Friday, June 23, 2017 5:29 AM
> To: Elvis Stansvik
> Cc: VTK Developers; Andrew Maclean
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>
>
>
> One thing I would point out is some folks who might want to compile
> the VTK examples may be using a slightly older version of VTK, and
> perhaps one that is not even being compiled with a modern compiler
> capable of compiling C++ 11...
>
> So I would refrain from using "auto" in the examples until such time
> as all the people who want to build an example are pretty much
> guaranteed to be using a VTK which requires C++ 11, and therefore a
> compiler capable of dealing with C++ 11 constructs.
>
> I wouldn't do the "auto" thing just yet.
>
>
> David C.
>
>
>
> On Fri, Jun 23, 2017 at 4:47 AM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
>> 2017-06-23 10:33 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>> Sorry, accidently hit send. Fixes below.
>>>
>>> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>>>>> Hi Bill, Elvis,
>>>>>    Elvis, personally I wouldn't like to see the homogenisation of the
>>>>> examples by doing what you propose.
>>>>> The reasons are:
>>>>> 1) One of the advantages of the examples is seeing the different
>>>>> approaches
>>>>> used by the contributors.
>>>>> 2) It may dissuade contributors by implicitly forcing them to use a
>>>>> particular approach.
>>>>> 3) One of the really useful things in the example is the different ways
>>>>> VTK
>>>>> is used.
>>>>
>>>> I absolutely agree with 1 and 3 (which I think are the same?), but I
>>>> don't see how changing to auto would in affect anything in this
>>>> regard.
>>>>
>>>> I also don't see how it would be a homogenization. The declarations I
>>>> would change are already homogeneous in that they're all
>>>> vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New(). Changing to auto
>>>> would not make it more or less homogeneous.
>>>>
>>>> It would be a
>>>
>>> ... It would be homogenisation if I'd change all
>>> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's not
>>> what this is about.
>>>
>>>> Note that this is not about changing vtkNew to vtkSmartPointer.
>>>>
>>>> And how would changing to auto in any way affect the approach taken by
>>>> the example?
>>>>
>>>>
>>>>
>>>>> To me it matters little whether:
>>>>> auto actor = vtkSmartPointer<vtkActor>::New();
>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>     vtkSmartPointer<vtkActor>::New();
>>>>>
>>>>> or whether "ren/renWin" is used instead of "renderer" or
>>>>> "rendererWindow" in
>>>>> the examples.
>>>
>>> It matters little to me too, but it does matter. I think it's almost
>>> indisputable that
>>>
>>>     auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
>>>
>>> is more readable than
>>>
>>>     vtkSmartPointer<SomeLongTypeName> someVar =
>>>         vtkSmartPointer<SomeLongTypeName>::New();
>>>
>>> especially since the latter leads to many more lines to scan across
>>> when looking for something in the examples.
>>
>> Another small plus I see with using auto is it's a keyword which would
>> be highlighted, so the declarations would stand out more.
>>
>> E.g. looking at the code for this example
>>
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Florensen.github.io%2FVTKExamples%2Fsite%2FCxx%2FFiltering%2FConnectivityFilter%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=ha%2BCR8CriMPmQqz%2FxrAgI6lQ7RKn21tuZ6Z%2FitzKD%2Fg%3D&reserved=0
>>
>> I find it hard to quickly answer "what are the declarations?", since
>> they have no highlighting compared to the surrounding statements. Had
>> they been auto, it would have been easier since I think auto would
>> have been highlighted.
>>
>> I think quickly identifying the variables involved helps the reading
>> of the examples.
>>
>> Elvis
>>
>>>
>>> So, in short I agree with everything you say, but I can't see how
>>> changing one way of doing declarations to another is a homogenization.
>>> And I do think spelling matters.
>>>
>>> I'm perfectly OK with leaving the examples exactly like they are
>>> though, just wanted to explain how I see it.
>>>
>>> Elvis
>>>
>>>>>
>>>>> Of more importance are explanatory notes in the examples.
>>>>>
>>>>> Bill, I see you are using vtkNamedColors. This example shows what other
>>>>> things you can do with this class:
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Florensen.github.io%2FVTKExamples%2Fsite%2FCxx%2FVisualization%2FNamedColors%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=jnbJJe87OvOErNapbQL2HiAt6DnbOWifp67W4lNVqfo%3D&reserved=0
>>>>>
>>>>> For example, assign colors by name:
>>>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetData
>>>>> ());
>>>>> Create your own named color (in this case a red with an alpha of 0.5):
>>>>> namedColors->GetColor("Red", rgba);
>>>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>>>>
>>>>> Regards
>>>>>    Andrew
>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>>>> Cc: vtkdev <vtk-developers at vtk.org>
>>>>>> Bcc:
>>>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
>>>>>> Let's leave them as is for now. I want to make sure I understand this.
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>> > 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>>> >> I'm not sure what you mean by auto-fying
>>>>>> >
>>>>>> > Sorry, I should have been clearer. What I mean is changing
>>>>>> > declarations
>>>>>> > such as
>>>>>> >
>>>>>> >
>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>> >     vtkSmartPointer<vtkActor>::New();
>>>>>> >
>>>>>> > into
>>>>>> >
>>>>>> >   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>> >
>>>>>> > I think it would cut down on the number of lines in many examples,
>>>>>> > and
>>>>>> > make them more readable. (This would only be done in places where
>>>>>> > the
>>>>>> > type of the variable is still clear from the declaration.)
>>>>>> >
>>>>>> > Elvis
>>>>>> >
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
>>>>>> >> <elvis.stansvik at orexplore.com> wrote:
>>>>>> >>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen
>>>>>> >>> <bill.lorensen at gmail.com>:
>>>>>> >>>> I prefer vtkSmartPointer because it can be used like any other
>>>>>> >>>> vtk
>>>>>> >>>> pointer. No need for a GetPointer() is some cases. The example
>>>>>> >>>> writer
>>>>>> >>>> is free to use vtkSmartPointer or vtkNew. But I would leave them
>>>>>> >>>> as
>>>>>> >>>> there are.
>>>>>> >>>
>>>>>> >>> Right, that's a valid point. But how about auto-fying the
>>>>>> >>> declarations? (but keep using vtkSmartPointer)
>>>>>> >>>
>>>>>> >>> My motivation is that when reading an example, I'm often squinting
>>>>>> >>> to
>>>>>> >>> find the variable names in the declarations, wedged in there
>>>>>> >>> somewhere
>>>>>> >>> between all those type names and angle brackets. Especially as the
>>>>>> >>> lines are often broken due to running long.
>>>>>> >>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> Other cleanup's sound great. I've also started using
>>>>>> >>>> vtkNamedColors
>>>>>> >>>> instead of setting float values.
>>>>>> >>>
>>>>>> >>> Great.
>>>>>> >>>
>>>>>> >>> Elvis
>>>>>> >>>
>>>>>> >>>>
>>>>>> >>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>>>>>> >>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>> >>>>> Hi all,
>>>>>> >>>>>
>>>>>> >>>>> How about a refactor of the examples to use vtkNew instead of
>>>>>> >>>>> vtkSmartPointer (where it makes sense)?
>>>>>> >>>>>
>>>>>> >>>>> E.g.
>>>>>> >>>>>
>>>>>> >>>>>   vtkNew<vtkActor> actor;
>>>>>> >>>>>   actor->SetMapper(mapper);
>>>>>> >>>>>
>>>>>> >>>>>   vtkNew<vtkRenderer> renderer;
>>>>>> >>>>>   renderer->AddActor(actor);
>>>>>> >>>>>
>>>>>> >>>>> instead of
>>>>>> >>>>>
>>>>>> >>>>>   vtkSmartPointer<vtkActor> actor =
>>>>>> >>>>>     vtkSmartPointer<vtkActor>::New();
>>>>>> >>>>>   actor->SetMapper(mapper);
>>>>>> >>>>>
>>>>>> >>>>>   vtkSmartPointer<vtkRenderer> renderer =
>>>>>> >>>>>     vtkSmartPointer<vtkRenderer>::New();
>>>>>> >>>>>   renderer->AddActor(actor);
>>>>>> >>>>>
>>>>>> >>>>> I think it would help with the readability of the examples. Or
>>>>>> >>>>> are
>>>>>> >>>>> there other reasons for the prevalent use of vtkSmartPointer?
>>>>>> >>>>>
>>>>>> >>>>> Another option would be to use auto, e.g.
>>>>>> >>>>>
>>>>>> >>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>> >>>>>
>>>>>> >>>>> Also, would anyone mind if I did a little naming cleanup, mostly
>>>>>> >>>>> things like "renwin" -> "window" and "iren" -> "interactor"?
>>>>>> >>>>> Those
>>>>>> >>>>> abbreviations are not that bad, but I think it's better in
>>>>>> >>>>> examples
>>>>>> >>>>> to
>>>>>> >>>>> spell out the variables in proper English.
>>>>>> >>>>>
>>>>>> >>>>> If there are no objections, I could try to prepare an MR when
>>>>>> >>>>> time
>>>>>> >>>>> permits. If so, vtkNew, or auto?
>>>>>> >>>>>
>>>>>> >>>>> Elvis
>>>>>> >>>>> _______________________________________________
>>>>>> >>>>> Powered by
>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>>>>>> >>>>>
>>>>>> >>>>> Visit other Kitware open-source projects at
>>>>>> >>>>>
>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
>>>>>> >>>>>
>>>>>> >>>>> Search the list archives at:
>>>>>> >>>>>
>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3OZk%3D&reserved=0
>>>>>> >>>>>
>>>>>> >>>>> Follow this link to subscribe/unsubscribe:
>>>>>> >>>>>
>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> --
>>>>>> >>>> Unpaid intern in BillsBasement at noware dot com
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Unpaid intern in BillsBasement at noware dot com
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ___________________________________________
>>>>> Andrew J. P. Maclean
>>>>>
>>>>> ___________________________________________
>> _______________________________________________
>> Powered by
>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>>
>> Visit other Kitware open-source projects at
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
>>
>> Search the list archives at:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3OZk%3D&reserved=0
>>
>> Follow this link to subscribe/unsubscribe:
>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>>
> _______________________________________________
> Powered by
> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>
> Visit other Kitware open-source projects at
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
>
> Search the list archives at:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3OZk%3D&reserved=0
>
> Follow this link to subscribe/unsubscribe:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>

From elvis.stansvik at orexplore.com  Fri Jun 23 07:58:28 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Fri, 23 Jun 2017 13:58:28 +0200
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
Message-ID: <CAE-7VJ=csNikKi94cFQrXW6+7OY+0TAVUnNA=f4yrOChMjEMHw@mail.gmail.com>

2017-06-23 11:29 GMT+02:00 David Cole <DLRdave at aol.com>:
> One thing I would point out is some folks who might want to compile
> the VTK examples may be using a slightly older version of VTK, and
> perhaps one that is not even being compiled with a modern compiler
> capable of compiling C++ 11...
>
> So I would refrain from using "auto" in the examples until such time
> as all the people who want to build an example are pretty much
> guaranteed to be using a VTK which requires C++ 11, and therefore a
> compiler capable of dealing with C++ 11 constructs.
>
> I wouldn't do the "auto" thing just yet.

Alright, that makes sense.

Elvis

>
>
> David C.
>
>
>
> On Fri, Jun 23, 2017 at 4:47 AM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
>> 2017-06-23 10:33 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>> Sorry, accidently hit send. Fixes below.
>>>
>>> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>>>>> Hi Bill, Elvis,
>>>>>    Elvis, personally I wouldn't like to see the homogenisation of the
>>>>> examples by doing what you propose.
>>>>> The reasons are:
>>>>> 1) One of the advantages of the examples is seeing the different approaches
>>>>> used by the contributors.
>>>>> 2) It may dissuade contributors by implicitly forcing them to use a
>>>>> particular approach.
>>>>> 3) One of the really useful things in the example is the different ways VTK
>>>>> is used.
>>>>
>>>> I absolutely agree with 1 and 3 (which I think are the same?), but I
>>>> don't see how changing to auto would in affect anything in this
>>>> regard.
>>>>
>>>> I also don't see how it would be a homogenization. The declarations I
>>>> would change are already homogeneous in that they're all
>>>> vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New(). Changing to auto
>>>> would not make it more or less homogeneous.
>>>>
>>>> It would be a
>>>
>>> ... It would be homogenisation if I'd change all
>>> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's not
>>> what this is about.
>>>
>>>> Note that this is not about changing vtkNew to vtkSmartPointer.
>>>>
>>>> And how would changing to auto in any way affect the approach taken by
>>>> the example?
>>>>
>>>>
>>>>
>>>>> To me it matters little whether:
>>>>> auto actor = vtkSmartPointer<vtkActor>::New();
>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>     vtkSmartPointer<vtkActor>::New();
>>>>>
>>>>> or whether "ren/renWin" is used instead of "renderer" or "rendererWindow" in
>>>>> the examples.
>>>
>>> It matters little to me too, but it does matter. I think it's almost
>>> indisputable that
>>>
>>>     auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
>>>
>>> is more readable than
>>>
>>>     vtkSmartPointer<SomeLongTypeName> someVar =
>>>         vtkSmartPointer<SomeLongTypeName>::New();
>>>
>>> especially since the latter leads to many more lines to scan across
>>> when looking for something in the examples.
>>
>> Another small plus I see with using auto is it's a keyword which would
>> be highlighted, so the declarations would stand out more.
>>
>> E.g. looking at the code for this example
>>
>>     https://lorensen.github.io/VTKExamples/site/Cxx/Filtering/ConnectivityFilter/
>>
>> I find it hard to quickly answer "what are the declarations?", since
>> they have no highlighting compared to the surrounding statements. Had
>> they been auto, it would have been easier since I think auto would
>> have been highlighted.
>>
>> I think quickly identifying the variables involved helps the reading
>> of the examples.
>>
>> Elvis
>>
>>>
>>> So, in short I agree with everything you say, but I can't see how
>>> changing one way of doing declarations to another is a homogenization.
>>> And I do think spelling matters.
>>>
>>> I'm perfectly OK with leaving the examples exactly like they are
>>> though, just wanted to explain how I see it.
>>>
>>> Elvis
>>>
>>>>>
>>>>> Of more importance are explanatory notes in the examples.
>>>>>
>>>>> Bill, I see you are using vtkNamedColors. This example shows what other
>>>>> things you can do with this class:
>>>>> https://lorensen.github.io/VTKExamples/site/Cxx/Visualization/NamedColors/
>>>>>
>>>>> For example, assign colors by name:
>>>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetData
>>>>> ());
>>>>> Create your own named color (in this case a red with an alpha of 0.5):
>>>>> namedColors->GetColor("Red", rgba);
>>>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>>>>
>>>>> Regards
>>>>>    Andrew
>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>>>> Cc: vtkdev <vtk-developers at vtk.org>
>>>>>> Bcc:
>>>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
>>>>>> Let's leave them as is for now. I want to make sure I understand this.
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>> > 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>>> >> I'm not sure what you mean by auto-fying
>>>>>> >
>>>>>> > Sorry, I should have been clearer. What I mean is changing declarations
>>>>>> > such as
>>>>>> >
>>>>>> >
>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>> >     vtkSmartPointer<vtkActor>::New();
>>>>>> >
>>>>>> > into
>>>>>> >
>>>>>> >   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>> >
>>>>>> > I think it would cut down on the number of lines in many examples, and
>>>>>> > make them more readable. (This would only be done in places where the
>>>>>> > type of the variable is still clear from the declaration.)
>>>>>> >
>>>>>> > Elvis
>>>>>> >
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
>>>>>> >> <elvis.stansvik at orexplore.com> wrote:
>>>>>> >>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>>> >>>> I prefer vtkSmartPointer because it can be used like any other vtk
>>>>>> >>>> pointer. No need for a GetPointer() is some cases. The example writer
>>>>>> >>>> is free to use vtkSmartPointer or vtkNew. But I would leave them as
>>>>>> >>>> there are.
>>>>>> >>>
>>>>>> >>> Right, that's a valid point. But how about auto-fying the
>>>>>> >>> declarations? (but keep using vtkSmartPointer)
>>>>>> >>>
>>>>>> >>> My motivation is that when reading an example, I'm often squinting to
>>>>>> >>> find the variable names in the declarations, wedged in there somewhere
>>>>>> >>> between all those type names and angle brackets. Especially as the
>>>>>> >>> lines are often broken due to running long.
>>>>>> >>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> Other cleanup's sound great. I've also started using vtkNamedColors
>>>>>> >>>> instead of setting float values.
>>>>>> >>>
>>>>>> >>> Great.
>>>>>> >>>
>>>>>> >>> Elvis
>>>>>> >>>
>>>>>> >>>>
>>>>>> >>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>>>>>> >>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>> >>>>> Hi all,
>>>>>> >>>>>
>>>>>> >>>>> How about a refactor of the examples to use vtkNew instead of
>>>>>> >>>>> vtkSmartPointer (where it makes sense)?
>>>>>> >>>>>
>>>>>> >>>>> E.g.
>>>>>> >>>>>
>>>>>> >>>>>   vtkNew<vtkActor> actor;
>>>>>> >>>>>   actor->SetMapper(mapper);
>>>>>> >>>>>
>>>>>> >>>>>   vtkNew<vtkRenderer> renderer;
>>>>>> >>>>>   renderer->AddActor(actor);
>>>>>> >>>>>
>>>>>> >>>>> instead of
>>>>>> >>>>>
>>>>>> >>>>>   vtkSmartPointer<vtkActor> actor =
>>>>>> >>>>>     vtkSmartPointer<vtkActor>::New();
>>>>>> >>>>>   actor->SetMapper(mapper);
>>>>>> >>>>>
>>>>>> >>>>>   vtkSmartPointer<vtkRenderer> renderer =
>>>>>> >>>>>     vtkSmartPointer<vtkRenderer>::New();
>>>>>> >>>>>   renderer->AddActor(actor);
>>>>>> >>>>>
>>>>>> >>>>> I think it would help with the readability of the examples. Or are
>>>>>> >>>>> there other reasons for the prevalent use of vtkSmartPointer?
>>>>>> >>>>>
>>>>>> >>>>> Another option would be to use auto, e.g.
>>>>>> >>>>>
>>>>>> >>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>> >>>>>
>>>>>> >>>>> Also, would anyone mind if I did a little naming cleanup, mostly
>>>>>> >>>>> things like "renwin" -> "window" and "iren" -> "interactor"? Those
>>>>>> >>>>> abbreviations are not that bad, but I think it's better in examples
>>>>>> >>>>> to
>>>>>> >>>>> spell out the variables in proper English.
>>>>>> >>>>>
>>>>>> >>>>> If there are no objections, I could try to prepare an MR when time
>>>>>> >>>>> permits. If so, vtkNew, or auto?
>>>>>> >>>>>
>>>>>> >>>>> Elvis
>>>>>> >>>>> _______________________________________________
>>>>>> >>>>> 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
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> --
>>>>>> >>>> Unpaid intern in BillsBasement at noware dot com
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Unpaid intern in BillsBasement at noware dot com
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ___________________________________________
>>>>> Andrew J. P. Maclean
>>>>>
>>>>> ___________________________________________
>> _______________________________________________
>> 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
>>

From lasso at queensu.ca  Fri Jun 23 08:23:23 2017
From: lasso at queensu.ca (Andras Lasso)
Date: Fri, 23 Jun 2017 12:23:23 +0000
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
Message-ID: <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>

> The reason for not allowing automatic conversion to pointer with vtkNew is to prevent people from returning a stale/dead pointer from a method.

It would be the same automatic conversion as in vtkSmartPointer. Nobody complains about that.

> It's safe to return a vtkSmartPointer from a method, and use the GetPointer from a vtkNew to do so, but not a raw pointer, unless you have some guarantee that some other reference to the pointer is keeping it alive.

The guarantee exists already. If the return type of the method is vtkSmartPointer then the vtkSmartPointer increments the reference count on the object before the local variable goes out of scope.

Andras

-----Original Message-----
From: David Cole [mailto:DLRdave at aol.com] 
Sent: Friday, June 23, 2017 7:24 AM
To: Andras Lasso <lasso at queensu.ca>
Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik <elvis.stansvik at orexplore.com>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21

The reason for not allowing automatic conversion to pointer with vtkNew is to prevent people from returning a stale/dead pointer from a method.

It would be disastrous to allow automatic conversion to a raw pointer.
The intent is to make it easy to create a local variable that goes away automatically when the scope closes. Allowing conversion to a raw pointer would make it very easy to write bad code.

It's safe to return a vtkSmartPointer from a method, and use the GetPointer from a vtkNew to do so, but not a raw pointer, unless you have some guarantee that some other reference to the pointer is keeping it alive.


HTH,
David C.




On Fri, Jun 23, 2017 at 7:04 AM, Andras Lasso <lasso at queensu.ca> wrote:
> I find vtkNew<?> to be the shortest and most readable way of creating 
> a new VTK object. However, it is rather inconvenient that GetPointer() 
> must be called to get the pointer. Is there a specific reason for 
> requiring using GetPointer()? Could we change vtkNew to have automatic 
> conversion to pointer type - the same way as in vtkSmartPointer?
>
>
>
> Andras
>
>
>
> From: David Cole via vtk-developers
> Sent: Friday, June 23, 2017 5:29 AM
> To: Elvis Stansvik
> Cc: VTK Developers; Andrew Maclean
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>
>
>
> One thing I would point out is some folks who might want to compile 
> the VTK examples may be using a slightly older version of VTK, and 
> perhaps one that is not even being compiled with a modern compiler 
> capable of compiling C++ 11...
>
> So I would refrain from using "auto" in the examples until such time 
> as all the people who want to build an example are pretty much 
> guaranteed to be using a VTK which requires C++ 11, and therefore a 
> compiler capable of dealing with C++ 11 constructs.
>
> I wouldn't do the "auto" thing just yet.
>
>
> David C.
>
>
>
> On Fri, Jun 23, 2017 at 4:47 AM, Elvis Stansvik 
> <elvis.stansvik at orexplore.com> wrote:
>> 2017-06-23 10:33 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>> Sorry, accidently hit send. Fixes below.
>>>
>>> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>>>>> Hi Bill, Elvis,
>>>>>    Elvis, personally I wouldn't like to see the homogenisation of 
>>>>> the examples by doing what you propose.
>>>>> The reasons are:
>>>>> 1) One of the advantages of the examples is seeing the different 
>>>>> approaches used by the contributors.
>>>>> 2) It may dissuade contributors by implicitly forcing them to use 
>>>>> a particular approach.
>>>>> 3) One of the really useful things in the example is the different 
>>>>> ways VTK is used.
>>>>
>>>> I absolutely agree with 1 and 3 (which I think are the same?), but 
>>>> I don't see how changing to auto would in affect anything in this 
>>>> regard.
>>>>
>>>> I also don't see how it would be a homogenization. The declarations 
>>>> I would change are already homogeneous in that they're all 
>>>> vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New(). Changing to 
>>>> auto would not make it more or less homogeneous.
>>>>
>>>> It would be a
>>>
>>> ... It would be homogenisation if I'd change all 
>>> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's 
>>> not what this is about.
>>>
>>>> Note that this is not about changing vtkNew to vtkSmartPointer.
>>>>
>>>> And how would changing to auto in any way affect the approach taken 
>>>> by the example?
>>>>
>>>>
>>>>
>>>>> To me it matters little whether:
>>>>> auto actor = vtkSmartPointer<vtkActor>::New(); 
>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>     vtkSmartPointer<vtkActor>::New();
>>>>>
>>>>> or whether "ren/renWin" is used instead of "renderer" or 
>>>>> "rendererWindow" in the examples.
>>>
>>> It matters little to me too, but it does matter. I think it's almost 
>>> indisputable that
>>>
>>>     auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
>>>
>>> is more readable than
>>>
>>>     vtkSmartPointer<SomeLongTypeName> someVar =
>>>         vtkSmartPointer<SomeLongTypeName>::New();
>>>
>>> especially since the latter leads to many more lines to scan across 
>>> when looking for something in the examples.
>>
>> Another small plus I see with using auto is it's a keyword which 
>> would be highlighted, so the declarations would stand out more.
>>
>> E.g. looking at the code for this example
>>
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
>> nsen.github.io%2FVTKExamples%2Fsite%2FCxx%2FFiltering%2FConnectivityF
>> ilter%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4
>> ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146
>> 481&sdata=ha%2BCR8CriMPmQqz%2FxrAgI6lQ7RKn21tuZ6Z%2FitzKD%2Fg%3D&rese
>> rved=0
>>
>> I find it hard to quickly answer "what are the declarations?", since 
>> they have no highlighting compared to the surrounding statements. Had 
>> they been auto, it would have been easier since I think auto would 
>> have been highlighted.
>>
>> I think quickly identifying the variables involved helps the reading 
>> of the examples.
>>
>> Elvis
>>
>>>
>>> So, in short I agree with everything you say, but I can't see how 
>>> changing one way of doing declarations to another is a homogenization.
>>> And I do think spelling matters.
>>>
>>> I'm perfectly OK with leaving the examples exactly like they are 
>>> though, just wanted to explain how I see it.
>>>
>>> Elvis
>>>
>>>>>
>>>>> Of more importance are explanatory notes in the examples.
>>>>>
>>>>> Bill, I see you are using vtkNamedColors. This example shows what 
>>>>> other things you can do with this class:
>>>>>
>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
>>>>> orensen.github.io%2FVTKExamples%2Fsite%2FCxx%2FVisualization%2FNam
>>>>> edColors%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f
>>>>> 2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338
>>>>> 069854146481&sdata=jnbJJe87OvOErNapbQL2HiAt6DnbOWifp67W4lNVqfo%3D&
>>>>> reserved=0
>>>>>
>>>>> For example, assign colors by name:
>>>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetDa
>>>>> renderer->ta
>>>>> ());
>>>>> Create your own named color (in this case a red with an alpha of 0.5):
>>>>> namedColors->GetColor("Red", rgba);
>>>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>>>>
>>>>> Regards
>>>>>    Andrew
>>>>>
>>>>>>
>>>>>> ---------- Forwarded message ----------
>>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>>>> Cc: vtkdev <vtk-developers at vtk.org>
>>>>>> Bcc:
>>>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?) Let's 
>>>>>> leave them as is for now. I want to make sure I understand this.
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik 
>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>> > 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>>> >> I'm not sure what you mean by auto-fying
>>>>>> >
>>>>>> > Sorry, I should have been clearer. What I mean is changing 
>>>>>> > declarations such as
>>>>>> >
>>>>>> >
>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>> >     vtkSmartPointer<vtkActor>::New();
>>>>>> >
>>>>>> > into
>>>>>> >
>>>>>> >   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>> >
>>>>>> > I think it would cut down on the number of lines in many 
>>>>>> > examples, and make them more readable. (This would only be done 
>>>>>> > in places where the type of the variable is still clear from 
>>>>>> > the declaration.)
>>>>>> >
>>>>>> > Elvis
>>>>>> >
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik 
>>>>>> >> <elvis.stansvik at orexplore.com> wrote:
>>>>>> >>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen
>>>>>> >>> <bill.lorensen at gmail.com>:
>>>>>> >>>> I prefer vtkSmartPointer because it can be used like any 
>>>>>> >>>> other vtk pointer. No need for a GetPointer() is some cases. 
>>>>>> >>>> The example writer is free to use vtkSmartPointer or vtkNew. 
>>>>>> >>>> But I would leave them as there are.
>>>>>> >>>
>>>>>> >>> Right, that's a valid point. But how about auto-fying the 
>>>>>> >>> declarations? (but keep using vtkSmartPointer)
>>>>>> >>>
>>>>>> >>> My motivation is that when reading an example, I'm often 
>>>>>> >>> squinting to find the variable names in the declarations, 
>>>>>> >>> wedged in there somewhere between all those type names and 
>>>>>> >>> angle brackets. Especially as the lines are often broken due 
>>>>>> >>> to running long.
>>>>>> >>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> Other cleanup's sound great. I've also started using 
>>>>>> >>>> vtkNamedColors instead of setting float values.
>>>>>> >>>
>>>>>> >>> Great.
>>>>>> >>>
>>>>>> >>> Elvis
>>>>>> >>>
>>>>>> >>>>
>>>>>> >>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik 
>>>>>> >>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>> >>>>> Hi all,
>>>>>> >>>>>
>>>>>> >>>>> How about a refactor of the examples to use vtkNew instead 
>>>>>> >>>>> of vtkSmartPointer (where it makes sense)?
>>>>>> >>>>>
>>>>>> >>>>> E.g.
>>>>>> >>>>>
>>>>>> >>>>>   vtkNew<vtkActor> actor;
>>>>>> >>>>>   actor->SetMapper(mapper);
>>>>>> >>>>>
>>>>>> >>>>>   vtkNew<vtkRenderer> renderer;
>>>>>> >>>>>   renderer->AddActor(actor);
>>>>>> >>>>>
>>>>>> >>>>> instead of
>>>>>> >>>>>
>>>>>> >>>>>   vtkSmartPointer<vtkActor> actor =
>>>>>> >>>>>     vtkSmartPointer<vtkActor>::New();
>>>>>> >>>>>   actor->SetMapper(mapper);
>>>>>> >>>>>
>>>>>> >>>>>   vtkSmartPointer<vtkRenderer> renderer =
>>>>>> >>>>>     vtkSmartPointer<vtkRenderer>::New();
>>>>>> >>>>>   renderer->AddActor(actor);
>>>>>> >>>>>
>>>>>> >>>>> I think it would help with the readability of the examples. 
>>>>>> >>>>> Or are there other reasons for the prevalent use of 
>>>>>> >>>>> vtkSmartPointer?
>>>>>> >>>>>
>>>>>> >>>>> Another option would be to use auto, e.g.
>>>>>> >>>>>
>>>>>> >>>>>   auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>> >>>>>
>>>>>> >>>>> Also, would anyone mind if I did a little naming cleanup, 
>>>>>> >>>>> mostly things like "renwin" -> "window" and "iren" -> "interactor"?
>>>>>> >>>>> Those
>>>>>> >>>>> abbreviations are not that bad, but I think it's better in 
>>>>>> >>>>> examples to spell out the variables in proper English.
>>>>>> >>>>>
>>>>>> >>>>> If there are no objections, I could try to prepare an MR 
>>>>>> >>>>> when time permits. If so, vtkNew, or auto?
>>>>>> >>>>>
>>>>>> >>>>> Elvis
>>>>>> >>>>> _______________________________________________
>>>>>> >>>>> Powered by
>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=www.kitw
>>>>>> >>>>> are.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7
>>>>>> >>>>> f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C
>>>>>> >>>>> 0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQ
>>>>>> >>>>> hA9SD%2Fxx0aWHI%3D&reserved=0
>>>>>> >>>>>
>>>>>> >>>>> Visit other Kitware open-source projects at
>>>>>> >>>>>
>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>> >>>>> 2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02
>>>>>> >>>>> %7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a62
>>>>>> >>>>> 17%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633806985
>>>>>> >>>>> 4146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOV
>>>>>> >>>>> fY%3D&reserved=0
>>>>>> >>>>>
>>>>>> >>>>> Search the list archives at:
>>>>>> >>>>>
>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>> >>>>> 2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%
>>>>>> >>>>> 7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a621
>>>>>> >>>>> 7%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854
>>>>>> >>>>> 146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3
>>>>>> >>>>> OZk%3D&reserved=0
>>>>>> >>>>>
>>>>>> >>>>> Follow this link to subscribe/unsubscribe:
>>>>>> >>>>>
>>>>>> >>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>> >>>>> 2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-develope
>>>>>> >>>>> rs&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f28
>>>>>> >>>>> 08d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C6
>>>>>> >>>>> 36338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJW
>>>>>> >>>>> VOoG27Zw%3D&reserved=0
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> --
>>>>>> >>>> Unpaid intern in BillsBasement at noware dot com
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Unpaid intern in BillsBasement at noware dot com
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ___________________________________________
>>>>> Andrew J. P. Maclean
>>>>>
>>>>> ___________________________________________
>> _______________________________________________
>> Powered by
>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&da
>> ta=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7C
>> d61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=M
>> OVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>>
>> Visit other Kitware open-source projects at
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.k
>> itware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40quee
>> nsu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb28
>> 38b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6
>> MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
>>
>> Search the list archives at:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkm
>> ail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queen
>> su.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb283
>> 8b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6S
>> OXUHrHWElowi%2B03r3OZk%3D&reserved=0
>>
>> Follow this link to subscribe/unsubscribe:
>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpubli
>> c.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Cla
>> sso%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d
>> 582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0
>> wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>>
> _______________________________________________
> Powered by
> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&dat
> a=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd6
> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOVh
> ItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>
> Visit other Kitware open-source projects at
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki
> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queens
> u.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b
> 925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSO
> dAv5BC3HClNEGOVfY%3D&reserved=0
>
> Search the list archives at:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkma
> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu
> .ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b9
> 25c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUH
> rHWElowi%2B03r3OZk%3D&reserved=0
>
> Follow this link to subscribe/unsubscribe:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic
> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>

From DLRdave at aol.com  Fri Jun 23 08:48:53 2017
From: DLRdave at aol.com (David Cole)
Date: Fri, 23 Jun 2017 08:48:53 -0400
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
Message-ID: <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>

Yes, and this was done intentionally to avoid the kinds of bugs people create when they don't think it all the way through. Forcing you to use Get or GetPointer forces you to think about it when that is what you're doing.

With vtkSmartPointer, it's possible to "return smartPointer;" from a method EVEN IF the return type of the method is a RAW pointer.

There's nothing illegal about it as long as you know there's a reference kept somewhere... but it makes it easier to get a pointer to a dead object and the designers of vtkNew explicitly wanted to avoid that problem.


David

On Jun 23, 2017, at 8:23 AM, Andras Lasso <lasso at queensu.ca> wrote:

>> The reason for not allowing automatic conversion to pointer with vtkNew is to prevent people from returning a stale/dead pointer from a method.
> 
> It would be the same automatic conversion as in vtkSmartPointer. Nobody complains about that.
> 
>> It's safe to return a vtkSmartPointer from a method, and use the GetPointer from a vtkNew to do so, but not a raw pointer, unless you have some guarantee that some other reference to the pointer is keeping it alive.
> 
> The guarantee exists already. If the return type of the method is vtkSmartPointer then the vtkSmartPointer increments the reference count on the object before the local variable goes out of scope.
> 
> Andras
> 
> -----Original Message-----
> From: David Cole [mailto:DLRdave at aol.com] 
> Sent: Friday, June 23, 2017 7:24 AM
> To: Andras Lasso <lasso at queensu.ca>
> Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik <elvis.stansvik at orexplore.com>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
> 
> The reason for not allowing automatic conversion to pointer with vtkNew is to prevent people from returning a stale/dead pointer from a method.
> 
> It would be disastrous to allow automatic conversion to a raw pointer.
> The intent is to make it easy to create a local variable that goes away automatically when the scope closes. Allowing conversion to a raw pointer would make it very easy to write bad code.
> 
> It's safe to return a vtkSmartPointer from a method, and use the GetPointer from a vtkNew to do so, but not a raw pointer, unless you have some guarantee that some other reference to the pointer is keeping it alive.
> 
> 
> HTH,
> David C.
> 
> 
> 
> 
>> On Fri, Jun 23, 2017 at 7:04 AM, Andras Lasso <lasso at queensu.ca> wrote:
>> I find vtkNew<?> to be the shortest and most readable way of creating 
>> a new VTK object. However, it is rather inconvenient that GetPointer() 
>> must be called to get the pointer. Is there a specific reason for 
>> requiring using GetPointer()? Could we change vtkNew to have automatic 
>> conversion to pointer type - the same way as in vtkSmartPointer?
>> 
>> 
>> 
>> Andras
>> 
>> 
>> 
>> From: David Cole via vtk-developers
>> Sent: Friday, June 23, 2017 5:29 AM
>> To: Elvis Stansvik
>> Cc: VTK Developers; Andrew Maclean
>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>> 
>> 
>> 
>> One thing I would point out is some folks who might want to compile 
>> the VTK examples may be using a slightly older version of VTK, and 
>> perhaps one that is not even being compiled with a modern compiler 
>> capable of compiling C++ 11...
>> 
>> So I would refrain from using "auto" in the examples until such time 
>> as all the people who want to build an example are pretty much 
>> guaranteed to be using a VTK which requires C++ 11, and therefore a 
>> compiler capable of dealing with C++ 11 constructs.
>> 
>> I wouldn't do the "auto" thing just yet.
>> 
>> 
>> David C.
>> 
>> 
>> 
>> On Fri, Jun 23, 2017 at 4:47 AM, Elvis Stansvik 
>> <elvis.stansvik at orexplore.com> wrote:
>>> 2017-06-23 10:33 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>> Sorry, accidently hit send. Fixes below.
>>>> 
>>>> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>>>>>> Hi Bill, Elvis,
>>>>>>   Elvis, personally I wouldn't like to see the homogenisation of 
>>>>>> the examples by doing what you propose.
>>>>>> The reasons are:
>>>>>> 1) One of the advantages of the examples is seeing the different 
>>>>>> approaches used by the contributors.
>>>>>> 2) It may dissuade contributors by implicitly forcing them to use 
>>>>>> a particular approach.
>>>>>> 3) One of the really useful things in the example is the different 
>>>>>> ways VTK is used.
>>>>> 
>>>>> I absolutely agree with 1 and 3 (which I think are the same?), but 
>>>>> I don't see how changing to auto would in affect anything in this 
>>>>> regard.
>>>>> 
>>>>> I also don't see how it would be a homogenization. The declarations 
>>>>> I would change are already homogeneous in that they're all 
>>>>> vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New(). Changing to 
>>>>> auto would not make it more or less homogeneous.
>>>>> 
>>>>> It would be a
>>>> 
>>>> ... It would be homogenisation if I'd change all 
>>>> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's 
>>>> not what this is about.
>>>> 
>>>>> Note that this is not about changing vtkNew to vtkSmartPointer.
>>>>> 
>>>>> And how would changing to auto in any way affect the approach taken 
>>>>> by the example?
>>>>> 
>>>>> 
>>>>> 
>>>>>> To me it matters little whether:
>>>>>> auto actor = vtkSmartPointer<vtkActor>::New(); 
>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>> 
>>>>>> or whether "ren/renWin" is used instead of "renderer" or 
>>>>>> "rendererWindow" in the examples.
>>>> 
>>>> It matters little to me too, but it does matter. I think it's almost 
>>>> indisputable that
>>>> 
>>>>    auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
>>>> 
>>>> is more readable than
>>>> 
>>>>    vtkSmartPointer<SomeLongTypeName> someVar =
>>>>        vtkSmartPointer<SomeLongTypeName>::New();
>>>> 
>>>> especially since the latter leads to many more lines to scan across 
>>>> when looking for something in the examples.
>>> 
>>> Another small plus I see with using auto is it's a keyword which 
>>> would be highlighted, so the declarations would stand out more.
>>> 
>>> E.g. looking at the code for this example
>>> 
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
>>> nsen.github.io%2FVTKExamples%2Fsite%2FCxx%2FFiltering%2FConnectivityF
>>> ilter%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4
>>> ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146
>>> 481&sdata=ha%2BCR8CriMPmQqz%2FxrAgI6lQ7RKn21tuZ6Z%2FitzKD%2Fg%3D&rese
>>> rved=0
>>> 
>>> I find it hard to quickly answer "what are the declarations?", since 
>>> they have no highlighting compared to the surrounding statements. Had 
>>> they been auto, it would have been easier since I think auto would 
>>> have been highlighted.
>>> 
>>> I think quickly identifying the variables involved helps the reading 
>>> of the examples.
>>> 
>>> Elvis
>>> 
>>>> 
>>>> So, in short I agree with everything you say, but I can't see how 
>>>> changing one way of doing declarations to another is a homogenization.
>>>> And I do think spelling matters.
>>>> 
>>>> I'm perfectly OK with leaving the examples exactly like they are 
>>>> though, just wanted to explain how I see it.
>>>> 
>>>> Elvis
>>>> 
>>>>>> 
>>>>>> Of more importance are explanatory notes in the examples.
>>>>>> 
>>>>>> Bill, I see you are using vtkNamedColors. This example shows what 
>>>>>> other things you can do with this class:
>>>>>> 
>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fl
>>>>>> orensen.github.io%2FVTKExamples%2Fsite%2FCxx%2FVisualization%2FNam
>>>>>> edColors%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f
>>>>>> 2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338
>>>>>> 069854146481&sdata=jnbJJe87OvOErNapbQL2HiAt6DnbOWifp67W4lNVqfo%3D&
>>>>>> reserved=0
>>>>>> 
>>>>>> For example, assign colors by name:
>>>>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetDa
>>>>>> renderer->ta
>>>>>> ());
>>>>>> Create your own named color (in this case a red with an alpha of 0.5):
>>>>>> namedColors->GetColor("Red", rgba);
>>>>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>>>>> 
>>>>>> Regards
>>>>>>   Andrew
>>>>>> 
>>>>>>> 
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>>>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>>>>> Cc: vtkdev <vtk-developers at vtk.org>
>>>>>>> Bcc:
>>>>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>>>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?) Let's 
>>>>>>> leave them as is for now. I want to make sure I understand this.
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik 
>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>> 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>>>>>> I'm not sure what you mean by auto-fying
>>>>>>>> 
>>>>>>>> Sorry, I should have been clearer. What I mean is changing 
>>>>>>>> declarations such as
>>>>>>>> 
>>>>>>>> 
>>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>>>> 
>>>>>>>> into
>>>>>>>> 
>>>>>>>>  auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>>>> 
>>>>>>>> I think it would cut down on the number of lines in many 
>>>>>>>> examples, and make them more readable. (This would only be done 
>>>>>>>> in places where the type of the variable is still clear from 
>>>>>>>> the declaration.)
>>>>>>>> 
>>>>>>>> Elvis
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik 
>>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>>>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen
>>>>>>>>>> <bill.lorensen at gmail.com>:
>>>>>>>>>>> I prefer vtkSmartPointer because it can be used like any 
>>>>>>>>>>> other vtk pointer. No need for a GetPointer() is some cases. 
>>>>>>>>>>> The example writer is free to use vtkSmartPointer or vtkNew. 
>>>>>>>>>>> But I would leave them as there are.
>>>>>>>>>> 
>>>>>>>>>> Right, that's a valid point. But how about auto-fying the 
>>>>>>>>>> declarations? (but keep using vtkSmartPointer)
>>>>>>>>>> 
>>>>>>>>>> My motivation is that when reading an example, I'm often 
>>>>>>>>>> squinting to find the variable names in the declarations, 
>>>>>>>>>> wedged in there somewhere between all those type names and 
>>>>>>>>>> angle brackets. Especially as the lines are often broken due 
>>>>>>>>>> to running long.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Other cleanup's sound great. I've also started using 
>>>>>>>>>>> vtkNamedColors instead of setting float values.
>>>>>>>>>> 
>>>>>>>>>> Great.
>>>>>>>>>> 
>>>>>>>>>> Elvis
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik 
>>>>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>> 
>>>>>>>>>>>> How about a refactor of the examples to use vtkNew instead 
>>>>>>>>>>>> of vtkSmartPointer (where it makes sense)?
>>>>>>>>>>>> 
>>>>>>>>>>>> E.g.
>>>>>>>>>>>> 
>>>>>>>>>>>>  vtkNew<vtkActor> actor;
>>>>>>>>>>>>  actor->SetMapper(mapper);
>>>>>>>>>>>> 
>>>>>>>>>>>>  vtkNew<vtkRenderer> renderer;
>>>>>>>>>>>>  renderer->AddActor(actor);
>>>>>>>>>>>> 
>>>>>>>>>>>> instead of
>>>>>>>>>>>> 
>>>>>>>>>>>>  vtkSmartPointer<vtkActor> actor =
>>>>>>>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>>>>>>>>  actor->SetMapper(mapper);
>>>>>>>>>>>> 
>>>>>>>>>>>>  vtkSmartPointer<vtkRenderer> renderer =
>>>>>>>>>>>>    vtkSmartPointer<vtkRenderer>::New();
>>>>>>>>>>>>  renderer->AddActor(actor);
>>>>>>>>>>>> 
>>>>>>>>>>>> I think it would help with the readability of the examples. 
>>>>>>>>>>>> Or are there other reasons for the prevalent use of 
>>>>>>>>>>>> vtkSmartPointer?
>>>>>>>>>>>> 
>>>>>>>>>>>> Another option would be to use auto, e.g.
>>>>>>>>>>>> 
>>>>>>>>>>>>  auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>>>>>>>> 
>>>>>>>>>>>> Also, would anyone mind if I did a little naming cleanup, 
>>>>>>>>>>>> mostly things like "renwin" -> "window" and "iren" -> "interactor"?
>>>>>>>>>>>> Those
>>>>>>>>>>>> abbreviations are not that bad, but I think it's better in 
>>>>>>>>>>>> examples to spell out the variables in proper English.
>>>>>>>>>>>> 
>>>>>>>>>>>> If there are no objections, I could try to prepare an MR 
>>>>>>>>>>>> when time permits. If so, vtkNew, or auto?
>>>>>>>>>>>> 
>>>>>>>>>>>> Elvis
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Powered by
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=www.kitw
>>>>>>>>>>>> are.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7
>>>>>>>>>>>> f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C
>>>>>>>>>>>> 0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQ
>>>>>>>>>>>> hA9SD%2Fxx0aWHI%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>>>> 
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>>>>>>>> 2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02
>>>>>>>>>>>> %7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a62
>>>>>>>>>>>> 17%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633806985
>>>>>>>>>>>> 4146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOV
>>>>>>>>>>>> fY%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> Search the list archives at:
>>>>>>>>>>>> 
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>>>>>>>> 2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%
>>>>>>>>>>>> 7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a621
>>>>>>>>>>>> 7%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854
>>>>>>>>>>>> 146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3
>>>>>>>>>>>> OZk%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>>> 
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>>>>>>>> 2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-develope
>>>>>>>>>>>> rs&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f28
>>>>>>>>>>>> 08d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C6
>>>>>>>>>>>> 36338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJW
>>>>>>>>>>>> VOoG27Zw%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> ___________________________________________
>>>>>> Andrew J. P. Maclean
>>>>>> 
>>>>>> ___________________________________________
>>> _______________________________________________
>>> Powered by
>>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&da
>>> ta=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7C
>>> d61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=M
>>> OVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>>> 
>>> Visit other Kitware open-source projects at
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.k
>>> itware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40quee
>>> nsu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb28
>>> 38b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6
>>> MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
>>> 
>>> Search the list archives at:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkm
>>> ail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queen
>>> su.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb283
>>> 8b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6S
>>> OXUHrHWElowi%2B03r3OZk%3D&reserved=0
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpubli
>>> c.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Cla
>>> sso%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d
>>> 582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0
>>> wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>>> 
>> _______________________________________________
>> Powered by
>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&dat
>> a=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd6
>> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOVh
>> ItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>> 
>> Visit other Kitware open-source projects at
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki
>> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queens
>> u.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b
>> 925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSO
>> dAv5BC3HClNEGOVfY%3D&reserved=0
>> 
>> Search the list archives at:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkma
>> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu
>> .ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b9
>> 25c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUH
>> rHWElowi%2B03r3OZk%3D&reserved=0
>> 
>> Follow this link to subscribe/unsubscribe:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic
>> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>> 


From lasso at queensu.ca  Fri Jun 23 09:11:34 2017
From: lasso at queensu.ca (Andras Lasso)
Date: Fri, 23 Jun 2017 13:11:34 +0000
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
Message-ID: <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>

> With vtkSmartPointer, it's possible to "return smartPointer;" from a method EVEN IF the return type of the method is a RAW pointer.

Well, this may be the main source of misunderstanding. Why do you think vtkSmartPointer would work any better in this case?

Have a look at the code below. Do you think it is safe to create an image and return it like that?

vtkImageData* CreateImage()
{
  vtkSmartPointer<vtkImageData> newImage = vtkSmartPointer<vtkImageData>::New();
  return newImage;
}

vtkImageData* myImage = CreateImage(); // is this safe?
vtkSmartPointer<vtkImageData>* myImage = CreateImage(); // is this safe?

Andras

-----Original Message-----
From: David Cole [mailto:DLRdave at aol.com] 
Sent: Friday, June 23, 2017 8:49 AM
To: Andras Lasso <lasso at queensu.ca>
Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik <elvis.stansvik at orexplore.com>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21

Yes, and this was done intentionally to avoid the kinds of bugs people create when they don't think it all the way through. Forcing you to use Get or GetPointer forces you to think about it when that is what you're doing.

With vtkSmartPointer, it's possible to "return smartPointer;" from a method EVEN IF the return type of the method is a RAW pointer.

There's nothing illegal about it as long as you know there's a reference kept somewhere... but it makes it easier to get a pointer to a dead object and the designers of vtkNew explicitly wanted to avoid that problem.


David

On Jun 23, 2017, at 8:23 AM, Andras Lasso <lasso at queensu.ca> wrote:

>> The reason for not allowing automatic conversion to pointer with vtkNew is to prevent people from returning a stale/dead pointer from a method.
> 
> It would be the same automatic conversion as in vtkSmartPointer. Nobody complains about that.
> 
>> It's safe to return a vtkSmartPointer from a method, and use the GetPointer from a vtkNew to do so, but not a raw pointer, unless you have some guarantee that some other reference to the pointer is keeping it alive.
> 
> The guarantee exists already. If the return type of the method is vtkSmartPointer then the vtkSmartPointer increments the reference count on the object before the local variable goes out of scope.
> 
> Andras
> 
> -----Original Message-----
> From: David Cole [mailto:DLRdave at aol.com]
> Sent: Friday, June 23, 2017 7:24 AM
> To: Andras Lasso <lasso at queensu.ca>
> Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik 
> <elvis.stansvik at orexplore.com>; VTK Developers 
> <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
> 
> The reason for not allowing automatic conversion to pointer with vtkNew is to prevent people from returning a stale/dead pointer from a method.
> 
> It would be disastrous to allow automatic conversion to a raw pointer.
> The intent is to make it easy to create a local variable that goes away automatically when the scope closes. Allowing conversion to a raw pointer would make it very easy to write bad code.
> 
> It's safe to return a vtkSmartPointer from a method, and use the GetPointer from a vtkNew to do so, but not a raw pointer, unless you have some guarantee that some other reference to the pointer is keeping it alive.
> 
> 
> HTH,
> David C.
> 
> 
> 
> 
>> On Fri, Jun 23, 2017 at 7:04 AM, Andras Lasso <lasso at queensu.ca> wrote:
>> I find vtkNew<?> to be the shortest and most readable way of creating 
>> a new VTK object. However, it is rather inconvenient that 
>> GetPointer() must be called to get the pointer. Is there a specific 
>> reason for requiring using GetPointer()? Could we change vtkNew to 
>> have automatic conversion to pointer type - the same way as in vtkSmartPointer?
>> 
>> 
>> 
>> Andras
>> 
>> 
>> 
>> From: David Cole via vtk-developers
>> Sent: Friday, June 23, 2017 5:29 AM
>> To: Elvis Stansvik
>> Cc: VTK Developers; Andrew Maclean
>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 
>> 21
>> 
>> 
>> 
>> One thing I would point out is some folks who might want to compile 
>> the VTK examples may be using a slightly older version of VTK, and 
>> perhaps one that is not even being compiled with a modern compiler 
>> capable of compiling C++ 11...
>> 
>> So I would refrain from using "auto" in the examples until such time 
>> as all the people who want to build an example are pretty much 
>> guaranteed to be using a VTK which requires C++ 11, and therefore a 
>> compiler capable of dealing with C++ 11 constructs.
>> 
>> I wouldn't do the "auto" thing just yet.
>> 
>> 
>> David C.
>> 
>> 
>> 
>> On Fri, Jun 23, 2017 at 4:47 AM, Elvis Stansvik 
>> <elvis.stansvik at orexplore.com> wrote:
>>> 2017-06-23 10:33 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>> Sorry, accidently hit send. Fixes below.
>>>> 
>>>> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>>>>>> Hi Bill, Elvis,
>>>>>>   Elvis, personally I wouldn't like to see the homogenisation of 
>>>>>> the examples by doing what you propose.
>>>>>> The reasons are:
>>>>>> 1) One of the advantages of the examples is seeing the different 
>>>>>> approaches used by the contributors.
>>>>>> 2) It may dissuade contributors by implicitly forcing them to use 
>>>>>> a particular approach.
>>>>>> 3) One of the really useful things in the example is the 
>>>>>> different ways VTK is used.
>>>>> 
>>>>> I absolutely agree with 1 and 3 (which I think are the same?), but 
>>>>> I don't see how changing to auto would in affect anything in this 
>>>>> regard.
>>>>> 
>>>>> I also don't see how it would be a homogenization. The 
>>>>> declarations I would change are already homogeneous in that 
>>>>> they're all vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New(). 
>>>>> Changing to auto would not make it more or less homogeneous.
>>>>> 
>>>>> It would be a
>>>> 
>>>> ... It would be homogenisation if I'd change all 
>>>> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's 
>>>> not what this is about.
>>>> 
>>>>> Note that this is not about changing vtkNew to vtkSmartPointer.
>>>>> 
>>>>> And how would changing to auto in any way affect the approach 
>>>>> taken by the example?
>>>>> 
>>>>> 
>>>>> 
>>>>>> To me it matters little whether:
>>>>>> auto actor = vtkSmartPointer<vtkActor>::New(); 
>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>> 
>>>>>> or whether "ren/renWin" is used instead of "renderer" or 
>>>>>> "rendererWindow" in the examples.
>>>> 
>>>> It matters little to me too, but it does matter. I think it's 
>>>> almost indisputable that
>>>> 
>>>>    auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
>>>> 
>>>> is more readable than
>>>> 
>>>>    vtkSmartPointer<SomeLongTypeName> someVar =
>>>>        vtkSmartPointer<SomeLongTypeName>::New();
>>>> 
>>>> especially since the latter leads to many more lines to scan across 
>>>> when looking for something in the examples.
>>> 
>>> Another small plus I see with using auto is it's a keyword which 
>>> would be highlighted, so the declarations would stand out more.
>>> 
>>> E.g. looking at the code for this example
>>> 
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor
>>> e 
>>> nsen.github.io%2FVTKExamples%2Fsite%2FCxx%2FFiltering%2FConnectivity
>>> F
>>> ilter%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d
>>> 4
>>> ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633806985414
>>> 6 
>>> 481&sdata=ha%2BCR8CriMPmQqz%2FxrAgI6lQ7RKn21tuZ6Z%2FitzKD%2Fg%3D&res
>>> e
>>> rved=0
>>> 
>>> I find it hard to quickly answer "what are the declarations?", since 
>>> they have no highlighting compared to the surrounding statements. 
>>> Had they been auto, it would have been easier since I think auto 
>>> would have been highlighted.
>>> 
>>> I think quickly identifying the variables involved helps the reading 
>>> of the examples.
>>> 
>>> Elvis
>>> 
>>>> 
>>>> So, in short I agree with everything you say, but I can't see how 
>>>> changing one way of doing declarations to another is a homogenization.
>>>> And I do think spelling matters.
>>>> 
>>>> I'm perfectly OK with leaving the examples exactly like they are 
>>>> though, just wanted to explain how I see it.
>>>> 
>>>> Elvis
>>>> 
>>>>>> 
>>>>>> Of more importance are explanatory notes in the examples.
>>>>>> 
>>>>>> Bill, I see you are using vtkNamedColors. This example shows what 
>>>>>> other things you can do with this class:
>>>>>> 
>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>> l 
>>>>>> orensen.github.io%2FVTKExamples%2Fsite%2FCxx%2FVisualization%2FNa
>>>>>> m 
>>>>>> edColors%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0
>>>>>> f
>>>>>> 2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633
>>>>>> 8 
>>>>>> 069854146481&sdata=jnbJJe87OvOErNapbQL2HiAt6DnbOWifp67W4lNVqfo%3D
>>>>>> &
>>>>>> reserved=0
>>>>>> 
>>>>>> For example, assign colors by name:
>>>>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetD
>>>>>> renderer->a
>>>>>> renderer->ta
>>>>>> ());
>>>>>> Create your own named color (in this case a red with an alpha of 0.5):
>>>>>> namedColors->GetColor("Red", rgba);
>>>>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>>>>> 
>>>>>> Regards
>>>>>>   Andrew
>>>>>> 
>>>>>>> 
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>>>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>>>>> Cc: vtkdev <vtk-developers at vtk.org>
>>>>>>> Bcc:
>>>>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>>>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?) 
>>>>>>> Let's leave them as is for now. I want to make sure I understand this.
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik 
>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>> 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>>>>>> I'm not sure what you mean by auto-fying
>>>>>>>> 
>>>>>>>> Sorry, I should have been clearer. What I mean is changing 
>>>>>>>> declarations such as
>>>>>>>> 
>>>>>>>> 
>>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>>>> 
>>>>>>>> into
>>>>>>>> 
>>>>>>>>  auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>>>> 
>>>>>>>> I think it would cut down on the number of lines in many 
>>>>>>>> examples, and make them more readable. (This would only be done 
>>>>>>>> in places where the type of the variable is still clear from 
>>>>>>>> the declaration.)
>>>>>>>> 
>>>>>>>> Elvis
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik 
>>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>>>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen
>>>>>>>>>> <bill.lorensen at gmail.com>:
>>>>>>>>>>> I prefer vtkSmartPointer because it can be used like any 
>>>>>>>>>>> other vtk pointer. No need for a GetPointer() is some cases.
>>>>>>>>>>> The example writer is free to use vtkSmartPointer or vtkNew. 
>>>>>>>>>>> But I would leave them as there are.
>>>>>>>>>> 
>>>>>>>>>> Right, that's a valid point. But how about auto-fying the 
>>>>>>>>>> declarations? (but keep using vtkSmartPointer)
>>>>>>>>>> 
>>>>>>>>>> My motivation is that when reading an example, I'm often 
>>>>>>>>>> squinting to find the variable names in the declarations, 
>>>>>>>>>> wedged in there somewhere between all those type names and 
>>>>>>>>>> angle brackets. Especially as the lines are often broken due 
>>>>>>>>>> to running long.
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Other cleanup's sound great. I've also started using 
>>>>>>>>>>> vtkNamedColors instead of setting float values.
>>>>>>>>>> 
>>>>>>>>>> Great.
>>>>>>>>>> 
>>>>>>>>>> Elvis
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik 
>>>>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>> 
>>>>>>>>>>>> How about a refactor of the examples to use vtkNew instead 
>>>>>>>>>>>> of vtkSmartPointer (where it makes sense)?
>>>>>>>>>>>> 
>>>>>>>>>>>> E.g.
>>>>>>>>>>>> 
>>>>>>>>>>>>  vtkNew<vtkActor> actor;
>>>>>>>>>>>>  actor->SetMapper(mapper);
>>>>>>>>>>>> 
>>>>>>>>>>>>  vtkNew<vtkRenderer> renderer;  renderer->AddActor(actor);
>>>>>>>>>>>> 
>>>>>>>>>>>> instead of
>>>>>>>>>>>> 
>>>>>>>>>>>>  vtkSmartPointer<vtkActor> actor =
>>>>>>>>>>>>    vtkSmartPointer<vtkActor>::New();  
>>>>>>>>>>>> actor->SetMapper(mapper);
>>>>>>>>>>>> 
>>>>>>>>>>>>  vtkSmartPointer<vtkRenderer> renderer =
>>>>>>>>>>>>    vtkSmartPointer<vtkRenderer>::New();
>>>>>>>>>>>>  renderer->AddActor(actor);
>>>>>>>>>>>> 
>>>>>>>>>>>> I think it would help with the readability of the examples. 
>>>>>>>>>>>> Or are there other reasons for the prevalent use of 
>>>>>>>>>>>> vtkSmartPointer?
>>>>>>>>>>>> 
>>>>>>>>>>>> Another option would be to use auto, e.g.
>>>>>>>>>>>> 
>>>>>>>>>>>>  auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>>>>>>>> 
>>>>>>>>>>>> Also, would anyone mind if I did a little naming cleanup, 
>>>>>>>>>>>> mostly things like "renwin" -> "window" and "iren" -> "interactor"?
>>>>>>>>>>>> Those
>>>>>>>>>>>> abbreviations are not that bad, but I think it's better in 
>>>>>>>>>>>> examples to spell out the variables in proper English.
>>>>>>>>>>>> 
>>>>>>>>>>>> If there are no objections, I could try to prepare an MR 
>>>>>>>>>>>> when time permits. If so, vtkNew, or auto?
>>>>>>>>>>>> 
>>>>>>>>>>>> Elvis
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Powered by
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=www.kitw
>>>>>>>>>>>> are.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7
>>>>>>>>>>>> f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C
>>>>>>>>>>>> 0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQ
>>>>>>>>>>>> hA9SD%2Fxx0aWHI%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>>>> 
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>>>>>>>> 2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02
>>>>>>>>>>>> %7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a62
>>>>>>>>>>>> 17%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633806985
>>>>>>>>>>>> 4146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOV
>>>>>>>>>>>> fY%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> Search the list archives at:
>>>>>>>>>>>> 
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>>>>>>>> 2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%
>>>>>>>>>>>> 7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a621
>>>>>>>>>>>> 7%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854
>>>>>>>>>>>> 146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3
>>>>>>>>>>>> OZk%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>>> 
>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>>>>>>>> 2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-develope
>>>>>>>>>>>> rs&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f28
>>>>>>>>>>>> 08d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C6
>>>>>>>>>>>> 36338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJW
>>>>>>>>>>>> VOoG27Zw%3D&reserved=0
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> ___________________________________________
>>>>>> Andrew J. P. Maclean
>>>>>> 
>>>>>> ___________________________________________
>>> _______________________________________________
>>> Powered by
>>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&d
>>> a 
>>> ta=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7
>>> C 
>>> d61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=
>>> M
>>> OVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>>> 
>>> Visit other Kitware open-source projects at 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>>> k 
>>> itware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40que
>>> e
>>> nsu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2
>>> 8
>>> 38b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B
>>> 6
>>> MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
>>> 
>>> Search the list archives at:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmark
>>> m 
>>> ail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40quee
>>> n
>>> su.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb28
>>> 3 
>>> 8b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6
>>> S
>>> OXUHrHWElowi%2B03r3OZk%3D&reserved=0
>>> 
>>> Follow this link to subscribe/unsubscribe:
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpubl
>>> i 
>>> c.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Cl
>>> a 
>>> sso%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142
>>> d
>>> 582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf
>>> 0
>>> wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>>> 
>> _______________________________________________
>> Powered by
>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&da
>> t
>> a=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd
>> 6 
>> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOV
>> h
>> ItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>> 
>> Visit other Kitware open-source projects at 
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.k
>> i 
>> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queen
>> s 
>> u.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838
>> b 
>> 925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnS
>> O
>> dAv5BC3HClNEGOVfY%3D&reserved=0
>> 
>> Search the list archives at:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkm
>> a 
>> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queens
>> u
>> .ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b
>> 9 
>> 25c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXU
>> H
>> rHWElowi%2B03r3OZk%3D&reserved=0
>> 
>> Follow this link to subscribe/unsubscribe:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpubli
>> c
>> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Clas
>> so%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d5
>> 82c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0w
>> QYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>> 


From DLRdave at aol.com  Fri Jun 23 10:38:00 2017
From: DLRdave at aol.com (David Cole)
Date: Fri, 23 Jun 2017 10:38:00 -0400
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
Message-ID: <CAKME8fEMcOWgS=4dw5QoMjFkvecL8HT5N3zR0qyxEjmiai3OjA@mail.gmail.com>

> vtkImageData* myImage = CreateImage(); // is this safe?

No, it's not.

> vtkSmartPointer<vtkImageData> myImage = CreateImage(); // is this safe?

Maybe, but I don't think it's guaranteed.

And the designers of vtkNew recognized that as a flaw in
vtkSmartPointer and insisted on creating the GetPointer method as a
safeguard against accidentally doing those things.

I'm not saying vtkSmartPointer is perfect: I'm saying vtkNew is an
IMPROVEMENT over it BECAUSE it doesn't have a cast to raw pointer
operator.

I feel like I've said the same thing 4 different ways now. I'll pause
and let others chime in if there is more discussion to be had...


D

On Fri, Jun 23, 2017 at 9:11 AM, Andras Lasso <lasso at queensu.ca> wrote:
>> With vtkSmartPointer, it's possible to "return smartPointer;" from a method EVEN IF the return type of the method is a RAW pointer.
>
> Well, this may be the main source of misunderstanding. Why do you think vtkSmartPointer would work any better in this case?
>
> Have a look at the code below. Do you think it is safe to create an image and return it like that?
>
> vtkImageData* CreateImage()
> {
>   vtkSmartPointer<vtkImageData> newImage = vtkSmartPointer<vtkImageData>::New();
>   return newImage;
> }
>
> vtkImageData* myImage = CreateImage(); // is this safe?
> vtkSmartPointer<vtkImageData>* myImage = CreateImage(); // is this safe?
>
> Andras
>
> -----Original Message-----
> From: David Cole [mailto:DLRdave at aol.com]
> Sent: Friday, June 23, 2017 8:49 AM
> To: Andras Lasso <lasso at queensu.ca>
> Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik <elvis.stansvik at orexplore.com>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>
> Yes, and this was done intentionally to avoid the kinds of bugs people create when they don't think it all the way through. Forcing you to use Get or GetPointer forces you to think about it when that is what you're doing.
>
> With vtkSmartPointer, it's possible to "return smartPointer;" from a method EVEN IF the return type of the method is a RAW pointer.
>
> There's nothing illegal about it as long as you know there's a reference kept somewhere... but it makes it easier to get a pointer to a dead object and the designers of vtkNew explicitly wanted to avoid that problem.
>
>
> David
>
> On Jun 23, 2017, at 8:23 AM, Andras Lasso <lasso at queensu.ca> wrote:
>
>>> The reason for not allowing automatic conversion to pointer with vtkNew is to prevent people from returning a stale/dead pointer from a method.
>>
>> It would be the same automatic conversion as in vtkSmartPointer. Nobody complains about that.
>>
>>> It's safe to return a vtkSmartPointer from a method, and use the GetPointer from a vtkNew to do so, but not a raw pointer, unless you have some guarantee that some other reference to the pointer is keeping it alive.
>>
>> The guarantee exists already. If the return type of the method is vtkSmartPointer then the vtkSmartPointer increments the reference count on the object before the local variable goes out of scope.
>>
>> Andras
>>
>> -----Original Message-----
>> From: David Cole [mailto:DLRdave at aol.com]
>> Sent: Friday, June 23, 2017 7:24 AM
>> To: Andras Lasso <lasso at queensu.ca>
>> Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik
>> <elvis.stansvik at orexplore.com>; VTK Developers
>> <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>>
>> The reason for not allowing automatic conversion to pointer with vtkNew is to prevent people from returning a stale/dead pointer from a method.
>>
>> It would be disastrous to allow automatic conversion to a raw pointer.
>> The intent is to make it easy to create a local variable that goes away automatically when the scope closes. Allowing conversion to a raw pointer would make it very easy to write bad code.
>>
>> It's safe to return a vtkSmartPointer from a method, and use the GetPointer from a vtkNew to do so, but not a raw pointer, unless you have some guarantee that some other reference to the pointer is keeping it alive.
>>
>>
>> HTH,
>> David C.
>>
>>
>>
>>
>>> On Fri, Jun 23, 2017 at 7:04 AM, Andras Lasso <lasso at queensu.ca> wrote:
>>> I find vtkNew<?> to be the shortest and most readable way of creating
>>> a new VTK object. However, it is rather inconvenient that
>>> GetPointer() must be called to get the pointer. Is there a specific
>>> reason for requiring using GetPointer()? Could we change vtkNew to
>>> have automatic conversion to pointer type - the same way as in vtkSmartPointer?
>>>
>>>
>>>
>>> Andras
>>>
>>>
>>>
>>> From: David Cole via vtk-developers
>>> Sent: Friday, June 23, 2017 5:29 AM
>>> To: Elvis Stansvik
>>> Cc: VTK Developers; Andrew Maclean
>>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue
>>> 21
>>>
>>>
>>>
>>> One thing I would point out is some folks who might want to compile
>>> the VTK examples may be using a slightly older version of VTK, and
>>> perhaps one that is not even being compiled with a modern compiler
>>> capable of compiling C++ 11...
>>>
>>> So I would refrain from using "auto" in the examples until such time
>>> as all the people who want to build an example are pretty much
>>> guaranteed to be using a VTK which requires C++ 11, and therefore a
>>> compiler capable of dealing with C++ 11 constructs.
>>>
>>> I wouldn't do the "auto" thing just yet.
>>>
>>>
>>> David C.
>>>
>>>
>>>
>>> On Fri, Jun 23, 2017 at 4:47 AM, Elvis Stansvik
>>> <elvis.stansvik at orexplore.com> wrote:
>>>> 2017-06-23 10:33 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>>> Sorry, accidently hit send. Fixes below.
>>>>>
>>>>> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>>>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>>>>>>> Hi Bill, Elvis,
>>>>>>>   Elvis, personally I wouldn't like to see the homogenisation of
>>>>>>> the examples by doing what you propose.
>>>>>>> The reasons are:
>>>>>>> 1) One of the advantages of the examples is seeing the different
>>>>>>> approaches used by the contributors.
>>>>>>> 2) It may dissuade contributors by implicitly forcing them to use
>>>>>>> a particular approach.
>>>>>>> 3) One of the really useful things in the example is the
>>>>>>> different ways VTK is used.
>>>>>>
>>>>>> I absolutely agree with 1 and 3 (which I think are the same?), but
>>>>>> I don't see how changing to auto would in affect anything in this
>>>>>> regard.
>>>>>>
>>>>>> I also don't see how it would be a homogenization. The
>>>>>> declarations I would change are already homogeneous in that
>>>>>> they're all vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New().
>>>>>> Changing to auto would not make it more or less homogeneous.
>>>>>>
>>>>>> It would be a
>>>>>
>>>>> ... It would be homogenisation if I'd change all
>>>>> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's
>>>>> not what this is about.
>>>>>
>>>>>> Note that this is not about changing vtkNew to vtkSmartPointer.
>>>>>>
>>>>>> And how would changing to auto in any way affect the approach
>>>>>> taken by the example?
>>>>>>
>>>>>>
>>>>>>
>>>>>>> To me it matters little whether:
>>>>>>> auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>>>
>>>>>>> or whether "ren/renWin" is used instead of "renderer" or
>>>>>>> "rendererWindow" in the examples.
>>>>>
>>>>> It matters little to me too, but it does matter. I think it's
>>>>> almost indisputable that
>>>>>
>>>>>    auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
>>>>>
>>>>> is more readable than
>>>>>
>>>>>    vtkSmartPointer<SomeLongTypeName> someVar =
>>>>>        vtkSmartPointer<SomeLongTypeName>::New();
>>>>>
>>>>> especially since the latter leads to many more lines to scan across
>>>>> when looking for something in the examples.
>>>>
>>>> Another small plus I see with using auto is it's a keyword which
>>>> would be highlighted, so the declarations would stand out more.
>>>>
>>>> E.g. looking at the code for this example
>>>>
>>>>
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor
>>>> e
>>>> nsen.github.io%2FVTKExamples%2Fsite%2FCxx%2FFiltering%2FConnectivity
>>>> F
>>>> ilter%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d
>>>> 4
>>>> ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633806985414
>>>> 6
>>>> 481&sdata=ha%2BCR8CriMPmQqz%2FxrAgI6lQ7RKn21tuZ6Z%2FitzKD%2Fg%3D&res
>>>> e
>>>> rved=0
>>>>
>>>> I find it hard to quickly answer "what are the declarations?", since
>>>> they have no highlighting compared to the surrounding statements.
>>>> Had they been auto, it would have been easier since I think auto
>>>> would have been highlighted.
>>>>
>>>> I think quickly identifying the variables involved helps the reading
>>>> of the examples.
>>>>
>>>> Elvis
>>>>
>>>>>
>>>>> So, in short I agree with everything you say, but I can't see how
>>>>> changing one way of doing declarations to another is a homogenization.
>>>>> And I do think spelling matters.
>>>>>
>>>>> I'm perfectly OK with leaving the examples exactly like they are
>>>>> though, just wanted to explain how I see it.
>>>>>
>>>>> Elvis
>>>>>
>>>>>>>
>>>>>>> Of more importance are explanatory notes in the examples.
>>>>>>>
>>>>>>> Bill, I see you are using vtkNamedColors. This example shows what
>>>>>>> other things you can do with this class:
>>>>>>>
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>>>>>>> l
>>>>>>> orensen.github.io%2FVTKExamples%2Fsite%2FCxx%2FVisualization%2FNa
>>>>>>> m
>>>>>>> edColors%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0
>>>>>>> f
>>>>>>> 2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633
>>>>>>> 8
>>>>>>> 069854146481&sdata=jnbJJe87OvOErNapbQL2HiAt6DnbOWifp67W4lNVqfo%3D
>>>>>>> &
>>>>>>> reserved=0
>>>>>>>
>>>>>>> For example, assign colors by name:
>>>>>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetD
>>>>>>> renderer->a
>>>>>>> renderer->ta
>>>>>>> ());
>>>>>>> Create your own named color (in this case a red with an alpha of 0.5):
>>>>>>> namedColors->GetColor("Red", rgba);
>>>>>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>>>>>>
>>>>>>> Regards
>>>>>>>   Andrew
>>>>>>>
>>>>>>>>
>>>>>>>> ---------- Forwarded message ----------
>>>>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>>>>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>>>>>> Cc: vtkdev <vtk-developers at vtk.org>
>>>>>>>> Bcc:
>>>>>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>>>>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
>>>>>>>> Let's leave them as is for now. I want to make sure I understand this.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>>> 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>>>>>>> I'm not sure what you mean by auto-fying
>>>>>>>>>
>>>>>>>>> Sorry, I should have been clearer. What I mean is changing
>>>>>>>>> declarations such as
>>>>>>>>>
>>>>>>>>>
>>>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>>>>>
>>>>>>>>> into
>>>>>>>>>
>>>>>>>>>  auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>>>>>
>>>>>>>>> I think it would cut down on the number of lines in many
>>>>>>>>> examples, and make them more readable. (This would only be done
>>>>>>>>> in places where the type of the variable is still clear from
>>>>>>>>> the declaration.)
>>>>>>>>>
>>>>>>>>> Elvis
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
>>>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>>>>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen
>>>>>>>>>>> <bill.lorensen at gmail.com>:
>>>>>>>>>>>> I prefer vtkSmartPointer because it can be used like any
>>>>>>>>>>>> other vtk pointer. No need for a GetPointer() is some cases.
>>>>>>>>>>>> The example writer is free to use vtkSmartPointer or vtkNew.
>>>>>>>>>>>> But I would leave them as there are.
>>>>>>>>>>>
>>>>>>>>>>> Right, that's a valid point. But how about auto-fying the
>>>>>>>>>>> declarations? (but keep using vtkSmartPointer)
>>>>>>>>>>>
>>>>>>>>>>> My motivation is that when reading an example, I'm often
>>>>>>>>>>> squinting to find the variable names in the declarations,
>>>>>>>>>>> wedged in there somewhere between all those type names and
>>>>>>>>>>> angle brackets. Especially as the lines are often broken due
>>>>>>>>>>> to running long.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Other cleanup's sound great. I've also started using
>>>>>>>>>>>> vtkNamedColors instead of setting float values.
>>>>>>>>>>>
>>>>>>>>>>> Great.
>>>>>>>>>>>
>>>>>>>>>>> Elvis
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
>>>>>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> How about a refactor of the examples to use vtkNew instead
>>>>>>>>>>>>> of vtkSmartPointer (where it makes sense)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> E.g.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  vtkNew<vtkActor> actor;
>>>>>>>>>>>>>  actor->SetMapper(mapper);
>>>>>>>>>>>>>
>>>>>>>>>>>>>  vtkNew<vtkRenderer> renderer;  renderer->AddActor(actor);
>>>>>>>>>>>>>
>>>>>>>>>>>>> instead of
>>>>>>>>>>>>>
>>>>>>>>>>>>>  vtkSmartPointer<vtkActor> actor =
>>>>>>>>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>>>>>>>>> actor->SetMapper(mapper);
>>>>>>>>>>>>>
>>>>>>>>>>>>>  vtkSmartPointer<vtkRenderer> renderer =
>>>>>>>>>>>>>    vtkSmartPointer<vtkRenderer>::New();
>>>>>>>>>>>>>  renderer->AddActor(actor);
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it would help with the readability of the examples.
>>>>>>>>>>>>> Or are there other reasons for the prevalent use of
>>>>>>>>>>>>> vtkSmartPointer?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another option would be to use auto, e.g.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, would anyone mind if I did a little naming cleanup,
>>>>>>>>>>>>> mostly things like "renwin" -> "window" and "iren" -> "interactor"?
>>>>>>>>>>>>> Those
>>>>>>>>>>>>> abbreviations are not that bad, but I think it's better in
>>>>>>>>>>>>> examples to spell out the variables in proper English.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If there are no objections, I could try to prepare an MR
>>>>>>>>>>>>> when time permits. If so, vtkNew, or auto?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Elvis
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Powered by
>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=www.kitw
>>>>>>>>>>>>> are.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7
>>>>>>>>>>>>> f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C
>>>>>>>>>>>>> 0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQ
>>>>>>>>>>>>> hA9SD%2Fxx0aWHI%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>>>>>>>>> 2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02
>>>>>>>>>>>>> %7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a62
>>>>>>>>>>>>> 17%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633806985
>>>>>>>>>>>>> 4146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOV
>>>>>>>>>>>>> fY%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Search the list archives at:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>>>>>>>>> 2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%
>>>>>>>>>>>>> 7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a621
>>>>>>>>>>>>> 7%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854
>>>>>>>>>>>>> 146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3
>>>>>>>>>>>>> OZk%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
>>>>>>>>>>>>> 2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-develope
>>>>>>>>>>>>> rs&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f28
>>>>>>>>>>>>> 08d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C6
>>>>>>>>>>>>> 36338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJW
>>>>>>>>>>>>> VOoG27Zw%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ___________________________________________
>>>>>>> Andrew J. P. Maclean
>>>>>>>
>>>>>>> ___________________________________________
>>>> _______________________________________________
>>>> Powered by
>>>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&d
>>>> a
>>>> ta=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7
>>>> C
>>>> d61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=
>>>> M
>>>> OVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>>>>
>>>> Visit other Kitware open-source projects at
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>>>> k
>>>> itware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40que
>>>> e
>>>> nsu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2
>>>> 8
>>>> 38b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B
>>>> 6
>>>> MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
>>>>
>>>> Search the list archives at:
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmark
>>>> m
>>>> ail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40quee
>>>> n
>>>> su.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb28
>>>> 3
>>>> 8b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6
>>>> S
>>>> OXUHrHWElowi%2B03r3OZk%3D&reserved=0
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>>
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpubl
>>>> i
>>>> c.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Cl
>>>> a
>>>> sso%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142
>>>> d
>>>> 582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf
>>>> 0
>>>> wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>>>>
>>> _______________________________________________
>>> Powered by
>>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&da
>>> t
>>> a=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd
>>> 6
>>> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOV
>>> h
>>> ItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>>>
>>> Visit other Kitware open-source projects at
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.k
>>> i
>>> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queen
>>> s
>>> u.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838
>>> b
>>> 925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnS
>>> O
>>> dAv5BC3HClNEGOVfY%3D&reserved=0
>>>
>>> Search the list archives at:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkm
>>> a
>>> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queens
>>> u
>>> .ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b
>>> 9
>>> 25c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXU
>>> H
>>> rHWElowi%2B03r3OZk%3D&reserved=0
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpubli
>>> c
>>> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Clas
>>> so%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d5
>>> 82c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0w
>>> QYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>>>
>

From shawn.waldon at kitware.com  Fri Jun 23 10:52:07 2017
From: shawn.waldon at kitware.com (Shawn Waldon)
Date: Fri, 23 Jun 2017 10:52:07 -0400
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
Message-ID: <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>

On Fri, Jun 23, 2017 at 9:11 AM, Andras Lasso <lasso at queensu.ca> wrote:

> > With vtkSmartPointer, it's possible to "return smartPointer;" from a
> method EVEN IF the return type of the method is a RAW pointer.
>
> Well, this may be the main source of misunderstanding. Why do you think
> vtkSmartPointer would work any better in this case?
>
> Have a look at the code below. Do you think it is safe to create an image
> and return it like that?
>
> vtkImageData* CreateImage()
> {
>   vtkSmartPointer<vtkImageData> newImage = vtkSmartPointer<vtkImageData>:
> :New();
>   return newImage;
> }
>
> vtkImageData* myImage = CreateImage(); // is this safe?
> vtkSmartPointer<vtkImageData>* myImage = CreateImage(); // is this safe?
>

Neither one of these is safe.  The image will be deleted when the smart
pointer goes out of scope but before the returned value is put into the
smart pointer in the calling function.  I understand what Elvis is saying
about the design of vtkNew wanting to make people think about when to call
Get/GetPointer.  I see their point.  But realistically what it does is
discourage use of vtkNew.  Most people I talk to say "I would use vtkNew
but then I have to clutter up my code with GetPointer calls everywhere" and
so they still use vtkSmartPointer.  Honestly I only used it to clean up
declarations (the problem discussed earlier in this thread).  Now that we
can use auto in VTK, I'll probably go back to vtkSmartPointer since it is
easier to use.

Shawn

>
> Andras
>
> -----Original Message-----
> From: David Cole [mailto:DLRdave at aol.com]
> Sent: Friday, June 23, 2017 8:49 AM
> To: Andras Lasso <lasso at queensu.ca>
> Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik <
> elvis.stansvik at orexplore.com>; VTK Developers <vtk-developers at vtk.org>;
> Andrew Maclean <andrew.amaclean at gmail.com>
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>
> Yes, and this was done intentionally to avoid the kinds of bugs people
> create when they don't think it all the way through. Forcing you to use Get
> or GetPointer forces you to think about it when that is what you're doing.
>
> With vtkSmartPointer, it's possible to "return smartPointer;" from a
> method EVEN IF the return type of the method is a RAW pointer.
>
> There's nothing illegal about it as long as you know there's a reference
> kept somewhere... but it makes it easier to get a pointer to a dead object
> and the designers of vtkNew explicitly wanted to avoid that problem.
>
>
> David
>
> On Jun 23, 2017, at 8:23 AM, Andras Lasso <lasso at queensu.ca> wrote:
>
> >> The reason for not allowing automatic conversion to pointer with vtkNew
> is to prevent people from returning a stale/dead pointer from a method.
> >
> > It would be the same automatic conversion as in vtkSmartPointer. Nobody
> complains about that.
> >
> >> It's safe to return a vtkSmartPointer from a method, and use the
> GetPointer from a vtkNew to do so, but not a raw pointer, unless you have
> some guarantee that some other reference to the pointer is keeping it alive.
> >
> > The guarantee exists already. If the return type of the method is
> vtkSmartPointer then the vtkSmartPointer increments the reference count on
> the object before the local variable goes out of scope.
> >
> > Andras
> >
> > -----Original Message-----
> > From: David Cole [mailto:DLRdave at aol.com]
> > Sent: Friday, June 23, 2017 7:24 AM
> > To: Andras Lasso <lasso at queensu.ca>
> > Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik
> > <elvis.stansvik at orexplore.com>; VTK Developers
> > <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
> > Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
> >
> > The reason for not allowing automatic conversion to pointer with vtkNew
> is to prevent people from returning a stale/dead pointer from a method.
> >
> > It would be disastrous to allow automatic conversion to a raw pointer.
> > The intent is to make it easy to create a local variable that goes away
> automatically when the scope closes. Allowing conversion to a raw pointer
> would make it very easy to write bad code.
> >
> > It's safe to return a vtkSmartPointer from a method, and use the
> GetPointer from a vtkNew to do so, but not a raw pointer, unless you have
> some guarantee that some other reference to the pointer is keeping it alive.
> >
> >
> > HTH,
> > David C.
> >
> >
> >
> >
> >> On Fri, Jun 23, 2017 at 7:04 AM, Andras Lasso <lasso at queensu.ca> wrote:
> >> I find vtkNew<?> to be the shortest and most readable way of creating
> >> a new VTK object. However, it is rather inconvenient that
> >> GetPointer() must be called to get the pointer. Is there a specific
> >> reason for requiring using GetPointer()? Could we change vtkNew to
> >> have automatic conversion to pointer type - the same way as in
> vtkSmartPointer?
> >>
> >>
> >>
> >> Andras
> >>
> >>
> >>
> >> From: David Cole via vtk-developers
> >> Sent: Friday, June 23, 2017 5:29 AM
> >> To: Elvis Stansvik
> >> Cc: VTK Developers; Andrew Maclean
> >> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue
> >> 21
> >>
> >>
> >>
> >> One thing I would point out is some folks who might want to compile
> >> the VTK examples may be using a slightly older version of VTK, and
> >> perhaps one that is not even being compiled with a modern compiler
> >> capable of compiling C++ 11...
> >>
> >> So I would refrain from using "auto" in the examples until such time
> >> as all the people who want to build an example are pretty much
> >> guaranteed to be using a VTK which requires C++ 11, and therefore a
> >> compiler capable of dealing with C++ 11 constructs.
> >>
> >> I wouldn't do the "auto" thing just yet.
> >>
> >>
> >> David C.
> >>
> >>
> >>
> >> On Fri, Jun 23, 2017 at 4:47 AM, Elvis Stansvik
> >> <elvis.stansvik at orexplore.com> wrote:
> >>> 2017-06-23 10:33 GMT+02:00 Elvis Stansvik <
> elvis.stansvik at orexplore.com>:
> >>>> Sorry, accidently hit send. Fixes below.
> >>>>
> >>>> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <
> elvis.stansvik at orexplore.com>:
> >>>>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com
> >:
> >>>>>> Hi Bill, Elvis,
> >>>>>>   Elvis, personally I wouldn't like to see the homogenisation of
> >>>>>> the examples by doing what you propose.
> >>>>>> The reasons are:
> >>>>>> 1) One of the advantages of the examples is seeing the different
> >>>>>> approaches used by the contributors.
> >>>>>> 2) It may dissuade contributors by implicitly forcing them to use
> >>>>>> a particular approach.
> >>>>>> 3) One of the really useful things in the example is the
> >>>>>> different ways VTK is used.
> >>>>>
> >>>>> I absolutely agree with 1 and 3 (which I think are the same?), but
> >>>>> I don't see how changing to auto would in affect anything in this
> >>>>> regard.
> >>>>>
> >>>>> I also don't see how it would be a homogenization. The
> >>>>> declarations I would change are already homogeneous in that
> >>>>> they're all vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New().
> >>>>> Changing to auto would not make it more or less homogeneous.
> >>>>>
> >>>>> It would be a
> >>>>
> >>>> ... It would be homogenisation if I'd change all
> >>>> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's
> >>>> not what this is about.
> >>>>
> >>>>> Note that this is not about changing vtkNew to vtkSmartPointer.
> >>>>>
> >>>>> And how would changing to auto in any way affect the approach
> >>>>> taken by the example?
> >>>>>
> >>>>>
> >>>>>
> >>>>>> To me it matters little whether:
> >>>>>> auto actor = vtkSmartPointer<vtkActor>::New();
> >>>>>> vtkSmartPointer<vtkActor> actor =
> >>>>>>    vtkSmartPointer<vtkActor>::New();
> >>>>>>
> >>>>>> or whether "ren/renWin" is used instead of "renderer" or
> >>>>>> "rendererWindow" in the examples.
> >>>>
> >>>> It matters little to me too, but it does matter. I think it's
> >>>> almost indisputable that
> >>>>
> >>>>    auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
> >>>>
> >>>> is more readable than
> >>>>
> >>>>    vtkSmartPointer<SomeLongTypeName> someVar =
> >>>>        vtkSmartPointer<SomeLongTypeName>::New();
> >>>>
> >>>> especially since the latter leads to many more lines to scan across
> >>>> when looking for something in the examples.
> >>>
> >>> Another small plus I see with using auto is it's a keyword which
> >>> would be highlighted, so the declarations would stand out more.
> >>>
> >>> E.g. looking at the code for this example
> >>>
> >>>
> >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor
> >>> e
> >>> nsen.github.io%2FVTKExamples%2Fsite%2FCxx%2FFiltering%2FConnectivity
> >>> F
> >>> ilter%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d
> >>> 4
> >>> ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633806985414
> >>> 6
> >>> 481&sdata=ha%2BCR8CriMPmQqz%2FxrAgI6lQ7RKn21tuZ6Z%2FitzKD%2Fg%3D&res
> >>> e
> >>> rved=0
> >>>
> >>> I find it hard to quickly answer "what are the declarations?", since
> >>> they have no highlighting compared to the surrounding statements.
> >>> Had they been auto, it would have been easier since I think auto
> >>> would have been highlighted.
> >>>
> >>> I think quickly identifying the variables involved helps the reading
> >>> of the examples.
> >>>
> >>> Elvis
> >>>
> >>>>
> >>>> So, in short I agree with everything you say, but I can't see how
> >>>> changing one way of doing declarations to another is a homogenization.
> >>>> And I do think spelling matters.
> >>>>
> >>>> I'm perfectly OK with leaving the examples exactly like they are
> >>>> though, just wanted to explain how I see it.
> >>>>
> >>>> Elvis
> >>>>
> >>>>>>
> >>>>>> Of more importance are explanatory notes in the examples.
> >>>>>>
> >>>>>> Bill, I see you are using vtkNamedColors. This example shows what
> >>>>>> other things you can do with this class:
> >>>>>>
> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >>>>>> l
> >>>>>> orensen.github.io%2FVTKExamples%2Fsite%2FCxx%2FVisualization%2FNa
> >>>>>> m
> >>>>>> edColors%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0
> >>>>>> f
> >>>>>> 2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633
> >>>>>> 8
> >>>>>> 069854146481&sdata=jnbJJe87OvOErNapbQL2HiAt6DnbOWifp67W4lNVqfo%3D
> >>>>>> &
> >>>>>> reserved=0
> >>>>>>
> >>>>>> For example, assign colors by name:
> >>>>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").GetD
> >>>>>> renderer->a
> >>>>>> renderer->ta
> >>>>>> ());
> >>>>>> Create your own named color (in this case a red with an alpha of
> 0.5):
> >>>>>> namedColors->GetColor("Red", rgba);
> >>>>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
> >>>>>>
> >>>>>> Regards
> >>>>>>   Andrew
> >>>>>>
> >>>>>>>
> >>>>>>> ---------- Forwarded message ----------
> >>>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
> >>>>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
> >>>>>>> Cc: vtkdev <vtk-developers at vtk.org>
> >>>>>>> Bcc:
> >>>>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
> >>>>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
> >>>>>>> Let's leave them as is for now. I want to make sure I understand
> this.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik
> >>>>>>> <elvis.stansvik at orexplore.com> wrote:
> >>>>>>>> 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com
> >:
> >>>>>>>>> I'm not sure what you mean by auto-fying
> >>>>>>>>
> >>>>>>>> Sorry, I should have been clearer. What I mean is changing
> >>>>>>>> declarations such as
> >>>>>>>>
> >>>>>>>>
> >>>>>>> vtkSmartPointer<vtkActor> actor =
> >>>>>>>>    vtkSmartPointer<vtkActor>::New();
> >>>>>>>>
> >>>>>>>> into
> >>>>>>>>
> >>>>>>>>  auto actor = vtkSmartPointer<vtkActor>::New();
> >>>>>>>>
> >>>>>>>> I think it would cut down on the number of lines in many
> >>>>>>>> examples, and make them more readable. (This would only be done
> >>>>>>>> in places where the type of the variable is still clear from
> >>>>>>>> the declaration.)
> >>>>>>>>
> >>>>>>>> Elvis
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik
> >>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
> >>>>>>>>>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen
> >>>>>>>>>> <bill.lorensen at gmail.com>:
> >>>>>>>>>>> I prefer vtkSmartPointer because it can be used like any
> >>>>>>>>>>> other vtk pointer. No need for a GetPointer() is some cases.
> >>>>>>>>>>> The example writer is free to use vtkSmartPointer or vtkNew.
> >>>>>>>>>>> But I would leave them as there are.
> >>>>>>>>>>
> >>>>>>>>>> Right, that's a valid point. But how about auto-fying the
> >>>>>>>>>> declarations? (but keep using vtkSmartPointer)
> >>>>>>>>>>
> >>>>>>>>>> My motivation is that when reading an example, I'm often
> >>>>>>>>>> squinting to find the variable names in the declarations,
> >>>>>>>>>> wedged in there somewhere between all those type names and
> >>>>>>>>>> angle brackets. Especially as the lines are often broken due
> >>>>>>>>>> to running long.
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Other cleanup's sound great. I've also started using
> >>>>>>>>>>> vtkNamedColors instead of setting float values.
> >>>>>>>>>>
> >>>>>>>>>> Great.
> >>>>>>>>>>
> >>>>>>>>>> Elvis
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik
> >>>>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
> >>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>
> >>>>>>>>>>>> How about a refactor of the examples to use vtkNew instead
> >>>>>>>>>>>> of vtkSmartPointer (where it makes sense)?
> >>>>>>>>>>>>
> >>>>>>>>>>>> E.g.
> >>>>>>>>>>>>
> >>>>>>>>>>>>  vtkNew<vtkActor> actor;
> >>>>>>>>>>>>  actor->SetMapper(mapper);
> >>>>>>>>>>>>
> >>>>>>>>>>>>  vtkNew<vtkRenderer> renderer;  renderer->AddActor(actor);
> >>>>>>>>>>>>
> >>>>>>>>>>>> instead of
> >>>>>>>>>>>>
> >>>>>>>>>>>>  vtkSmartPointer<vtkActor> actor =
> >>>>>>>>>>>>    vtkSmartPointer<vtkActor>::New();
> >>>>>>>>>>>> actor->SetMapper(mapper);
> >>>>>>>>>>>>
> >>>>>>>>>>>>  vtkSmartPointer<vtkRenderer> renderer =
> >>>>>>>>>>>>    vtkSmartPointer<vtkRenderer>::New();
> >>>>>>>>>>>>  renderer->AddActor(actor);
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think it would help with the readability of the examples.
> >>>>>>>>>>>> Or are there other reasons for the prevalent use of
> >>>>>>>>>>>> vtkSmartPointer?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Another option would be to use auto, e.g.
> >>>>>>>>>>>>
> >>>>>>>>>>>>  auto actor = vtkSmartPointer<vtkActor>::New();
> >>>>>>>>>>>>
> >>>>>>>>>>>> Also, would anyone mind if I did a little naming cleanup,
> >>>>>>>>>>>> mostly things like "renwin" -> "window" and "iren" ->
> "interactor"?
> >>>>>>>>>>>> Those
> >>>>>>>>>>>> abbreviations are not that bad, but I think it's better in
> >>>>>>>>>>>> examples to spell out the variables in proper English.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If there are no objections, I could try to prepare an MR
> >>>>>>>>>>>> when time permits. If so, vtkNew, or auto?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Elvis
> >>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>> Powered by
> >>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=www.kitw
> >>>>>>>>>>>> are.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7
> >>>>>>>>>>>> f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C
> >>>>>>>>>>>> 0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthSQ
> >>>>>>>>>>>> hA9SD%2Fxx0aWHI%3D&reserved=0
> >>>>>>>>>>>>
> >>>>>>>>>>>> Visit other Kitware open-source projects at
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
> >>>>>>>>>>>> 2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02
> >>>>>>>>>>>> %7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a62
> >>>>>>>>>>>> 17%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633806985
> >>>>>>>>>>>> 4146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGOV
> >>>>>>>>>>>> fY%3D&reserved=0
> >>>>>>>>>>>>
> >>>>>>>>>>>> Search the list archives at:
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
> >>>>>>>>>>>> 2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%
> >>>>>>>>>>>> 7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a621
> >>>>>>>>>>>> 7%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854
> >>>>>>>>>>>> 146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r3
> >>>>>>>>>>>> OZk%3D&reserved=0
> >>>>>>>>>>>>
> >>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%
> >>>>>>>>>>>> 2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-develope
> >>>>>>>>>>>> rs&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f28
> >>>>>>>>>>>> 08d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C6
> >>>>>>>>>>>> 36338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJW
> >>>>>>>>>>>> VOoG27Zw%3D&reserved=0
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Unpaid intern in BillsBasement at noware dot com
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Unpaid intern in BillsBasement at noware dot com
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Unpaid intern in BillsBasement at noware dot com
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> ___________________________________________
> >>>>>> Andrew J. P. Maclean
> >>>>>>
> >>>>>> ___________________________________________
> >>> _______________________________________________
> >>> Powered by
> >>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&d
> >>> a
> >>> ta=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7
> >>> C
> >>> d61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=
> >>> M
> >>> OVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
> >>>
> >>> Visit other Kitware open-source projects at
> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> >>> k
> >>> itware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40que
> >>> e
> >>> nsu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2
> >>> 8
> >>> 38b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B
> >>> 6
> >>> MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
> >>>
> >>> Search the list archives at:
> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmark
> >>> m
> >>> ail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40quee
> >>> n
> >>> su.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb28
> >>> 3
> >>> 8b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6
> >>> S
> >>> OXUHrHWElowi%2B03r3OZk%3D&reserved=0
> >>>
> >>> Follow this link to subscribe/unsubscribe:
> >>>
> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpubl
> >>> i
> >>> c.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Cl
> >>> a
> >>> sso%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142
> >>> d
> >>> 582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf
> >>> 0
> >>> wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
> >>>
> >> _______________________________________________
> >> Powered by
> >> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&da
> >> t
> >> a=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd
> >> 6
> >> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MOV
> >> h
> >> ItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
> >>
> >> Visit other Kitware open-source projects at
> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.k
> >> i
> >> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queen
> >> s
> >> u.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838
> >> b
> >> 925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnS
> >> O
> >> dAv5BC3HClNEGOVfY%3D&reserved=0
> >>
> >> Search the list archives at:
> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkm
> >> a
> >> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queens
> >> u
> >> .ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b
> >> 9
> >> 25c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXU
> >> H
> >> rHWElowi%2B03r3OZk%3D&reserved=0
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpubli
> >> c
> >> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Clas
> >> so%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d5
> >> 82c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0w
> >> QYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
> >>
>
> _______________________________________________
> 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/20170623/d7b7295e/attachment-0001.html>

From lasso at queensu.ca  Fri Jun 23 11:12:04 2017
From: lasso at queensu.ca (Andras Lasso)
Date: Fri, 23 Jun 2017 15:12:04 +0000
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAKME8fEMcOWgS=4dw5QoMjFkvecL8HT5N3zR0qyxEjmiai3OjA@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fEMcOWgS=4dw5QoMjFkvecL8HT5N3zR0qyxEjmiai3OjA@mail.gmail.com>
Message-ID: <BY2PR0701MB1941FD903F5648711B9E17FBD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>

OK, great, so we agree that there is no difference in safety in vtkSmartPointer with implicit pointer cast and vtkNew with implicit pointer cast. It's all about personal preference now: is implicit cast a feature or a flaw.

To not burden the mailing list with votes, I've created this poll - please mark your preference - either for keeping or changing current behavior:
https://goo.gl/forms/MEkBKvyBXfyPQ1Aj1

Andras

-----Original Message-----
From: David Cole [mailto:DLRdave at aol.com] 
Sent: Friday, June 23, 2017 10:38 AM
To: Andras Lasso <lasso at queensu.ca>
Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik <elvis.stansvik at orexplore.com>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21

> vtkImageData* myImage = CreateImage(); // is this safe?

No, it's not.

> vtkSmartPointer<vtkImageData> myImage = CreateImage(); // is this safe?

Maybe, but I don't think it's guaranteed.

And the designers of vtkNew recognized that as a flaw in vtkSmartPointer and insisted on creating the GetPointer method as a safeguard against accidentally doing those things.

I'm not saying vtkSmartPointer is perfect: I'm saying vtkNew is an IMPROVEMENT over it BECAUSE it doesn't have a cast to raw pointer operator.

I feel like I've said the same thing 4 different ways now. I'll pause and let others chime in if there is more discussion to be had...


D

On Fri, Jun 23, 2017 at 9:11 AM, Andras Lasso <lasso at queensu.ca> wrote:
>> With vtkSmartPointer, it's possible to "return smartPointer;" from a method EVEN IF the return type of the method is a RAW pointer.
>
> Well, this may be the main source of misunderstanding. Why do you think vtkSmartPointer would work any better in this case?
>
> Have a look at the code below. Do you think it is safe to create an image and return it like that?
>
> vtkImageData* CreateImage()
> {
>   vtkSmartPointer<vtkImageData> newImage = vtkSmartPointer<vtkImageData>::New();
>   return newImage;
> }
>
> vtkImageData* myImage = CreateImage(); // is this safe?
> vtkSmartPointer<vtkImageData>* myImage = CreateImage(); // is this safe?
>
> Andras
>
> -----Original Message-----
> From: David Cole [mailto:DLRdave at aol.com]
> Sent: Friday, June 23, 2017 8:49 AM
> To: Andras Lasso <lasso at queensu.ca>
> Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik 
> <elvis.stansvik at orexplore.com>; VTK Developers 
> <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>
> Yes, and this was done intentionally to avoid the kinds of bugs people create when they don't think it all the way through. Forcing you to use Get or GetPointer forces you to think about it when that is what you're doing.
>
> With vtkSmartPointer, it's possible to "return smartPointer;" from a method EVEN IF the return type of the method is a RAW pointer.
>
> There's nothing illegal about it as long as you know there's a reference kept somewhere... but it makes it easier to get a pointer to a dead object and the designers of vtkNew explicitly wanted to avoid that problem.
>
>
> David
>
> On Jun 23, 2017, at 8:23 AM, Andras Lasso <lasso at queensu.ca> wrote:
>
>>> The reason for not allowing automatic conversion to pointer with vtkNew is to prevent people from returning a stale/dead pointer from a method.
>>
>> It would be the same automatic conversion as in vtkSmartPointer. Nobody complains about that.
>>
>>> It's safe to return a vtkSmartPointer from a method, and use the GetPointer from a vtkNew to do so, but not a raw pointer, unless you have some guarantee that some other reference to the pointer is keeping it alive.
>>
>> The guarantee exists already. If the return type of the method is vtkSmartPointer then the vtkSmartPointer increments the reference count on the object before the local variable goes out of scope.
>>
>> Andras
>>
>> -----Original Message-----
>> From: David Cole [mailto:DLRdave at aol.com]
>> Sent: Friday, June 23, 2017 7:24 AM
>> To: Andras Lasso <lasso at queensu.ca>
>> Cc: David Cole <DLRdave at aol.com>; Elvis Stansvik 
>> <elvis.stansvik at orexplore.com>; VTK Developers 
>> <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 
>> 21
>>
>> The reason for not allowing automatic conversion to pointer with vtkNew is to prevent people from returning a stale/dead pointer from a method.
>>
>> It would be disastrous to allow automatic conversion to a raw pointer.
>> The intent is to make it easy to create a local variable that goes away automatically when the scope closes. Allowing conversion to a raw pointer would make it very easy to write bad code.
>>
>> It's safe to return a vtkSmartPointer from a method, and use the GetPointer from a vtkNew to do so, but not a raw pointer, unless you have some guarantee that some other reference to the pointer is keeping it alive.
>>
>>
>> HTH,
>> David C.
>>
>>
>>
>>
>>> On Fri, Jun 23, 2017 at 7:04 AM, Andras Lasso <lasso at queensu.ca> wrote:
>>> I find vtkNew<?> to be the shortest and most readable way of 
>>> creating a new VTK object. However, it is rather inconvenient that
>>> GetPointer() must be called to get the pointer. Is there a specific 
>>> reason for requiring using GetPointer()? Could we change vtkNew to 
>>> have automatic conversion to pointer type - the same way as in vtkSmartPointer?
>>>
>>>
>>>
>>> Andras
>>>
>>>
>>>
>>> From: David Cole via vtk-developers
>>> Sent: Friday, June 23, 2017 5:29 AM
>>> To: Elvis Stansvik
>>> Cc: VTK Developers; Andrew Maclean
>>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue
>>> 21
>>>
>>>
>>>
>>> One thing I would point out is some folks who might want to compile 
>>> the VTK examples may be using a slightly older version of VTK, and 
>>> perhaps one that is not even being compiled with a modern compiler 
>>> capable of compiling C++ 11...
>>>
>>> So I would refrain from using "auto" in the examples until such time 
>>> as all the people who want to build an example are pretty much 
>>> guaranteed to be using a VTK which requires C++ 11, and therefore a 
>>> compiler capable of dealing with C++ 11 constructs.
>>>
>>> I wouldn't do the "auto" thing just yet.
>>>
>>>
>>> David C.
>>>
>>>
>>>
>>> On Fri, Jun 23, 2017 at 4:47 AM, Elvis Stansvik 
>>> <elvis.stansvik at orexplore.com> wrote:
>>>> 2017-06-23 10:33 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>>> Sorry, accidently hit send. Fixes below.
>>>>>
>>>>> 2017-06-23 10:29 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>>>>> 2017-06-23 1:21 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
>>>>>>> Hi Bill, Elvis,
>>>>>>>   Elvis, personally I wouldn't like to see the homogenisation of 
>>>>>>> the examples by doing what you propose.
>>>>>>> The reasons are:
>>>>>>> 1) One of the advantages of the examples is seeing the different 
>>>>>>> approaches used by the contributors.
>>>>>>> 2) It may dissuade contributors by implicitly forcing them to 
>>>>>>> use a particular approach.
>>>>>>> 3) One of the really useful things in the example is the 
>>>>>>> different ways VTK is used.
>>>>>>
>>>>>> I absolutely agree with 1 and 3 (which I think are the same?), 
>>>>>> but I don't see how changing to auto would in affect anything in 
>>>>>> this regard.
>>>>>>
>>>>>> I also don't see how it would be a homogenization. The 
>>>>>> declarations I would change are already homogeneous in that 
>>>>>> they're all vtkSmartPointer<Foo> a = vtkSmartPointer<Foo>::New().
>>>>>> Changing to auto would not make it more or less homogeneous.
>>>>>>
>>>>>> It would be a
>>>>>
>>>>> ... It would be homogenisation if I'd change all 
>>>>> vtkNew/vtkSmartPointer to auto a = vtkSmartPointer..., but that's 
>>>>> not what this is about.
>>>>>
>>>>>> Note that this is not about changing vtkNew to vtkSmartPointer.
>>>>>>
>>>>>> And how would changing to auto in any way affect the approach 
>>>>>> taken by the example?
>>>>>>
>>>>>>
>>>>>>
>>>>>>> To me it matters little whether:
>>>>>>> auto actor = vtkSmartPointer<vtkActor>::New(); 
>>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>>>
>>>>>>> or whether "ren/renWin" is used instead of "renderer" or 
>>>>>>> "rendererWindow" in the examples.
>>>>>
>>>>> It matters little to me too, but it does matter. I think it's 
>>>>> almost indisputable that
>>>>>
>>>>>    auto someVar = vtkSmartPointer<SomeLongTypeName>::New()
>>>>>
>>>>> is more readable than
>>>>>
>>>>>    vtkSmartPointer<SomeLongTypeName> someVar =
>>>>>        vtkSmartPointer<SomeLongTypeName>::New();
>>>>>
>>>>> especially since the latter leads to many more lines to scan 
>>>>> across when looking for something in the examples.
>>>>
>>>> Another small plus I see with using auto is it's a keyword which 
>>>> would be highlighted, so the declarations would stand out more.
>>>>
>>>> E.g. looking at the code for this example
>>>>
>>>>
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flo
>>>> r
>>>> e
>>>> nsen.github.io%2FVTKExamples%2Fsite%2FCxx%2FFiltering%2FConnectivit
>>>> y
>>>> F
>>>> ilter%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808
>>>> d
>>>> 4
>>>> ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C6363380698541
>>>> 4
>>>> 6
>>>> 481&sdata=ha%2BCR8CriMPmQqz%2FxrAgI6lQ7RKn21tuZ6Z%2FitzKD%2Fg%3D&re
>>>> s
>>>> e
>>>> rved=0
>>>>
>>>> I find it hard to quickly answer "what are the declarations?", 
>>>> since they have no highlighting compared to the surrounding statements.
>>>> Had they been auto, it would have been easier since I think auto 
>>>> would have been highlighted.
>>>>
>>>> I think quickly identifying the variables involved helps the 
>>>> reading of the examples.
>>>>
>>>> Elvis
>>>>
>>>>>
>>>>> So, in short I agree with everything you say, but I can't see how 
>>>>> changing one way of doing declarations to another is a homogenization.
>>>>> And I do think spelling matters.
>>>>>
>>>>> I'm perfectly OK with leaving the examples exactly like they are 
>>>>> though, just wanted to explain how I see it.
>>>>>
>>>>> Elvis
>>>>>
>>>>>>>
>>>>>>> Of more importance are explanatory notes in the examples.
>>>>>>>
>>>>>>> Bill, I see you are using vtkNamedColors. This example shows 
>>>>>>> what other things you can do with this class:
>>>>>>>
>>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>>> F
>>>>>>> l
>>>>>>> orensen.github.io%2FVTKExamples%2Fsite%2FCxx%2FVisualization%2FN
>>>>>>> a
>>>>>>> m
>>>>>>> edColors%2F&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f
>>>>>>> 0
>>>>>>> f
>>>>>>> 2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C6363
>>>>>>> 3
>>>>>>> 8
>>>>>>> 069854146481&sdata=jnbJJe87OvOErNapbQL2HiAt6DnbOWifp67W4lNVqfo%3
>>>>>>> D
>>>>>>> &
>>>>>>> reserved=0
>>>>>>>
>>>>>>> For example, assign colors by name:
>>>>>>> renderer->SetBackground(namedColors->GetColor3d("SteelBlue").Get
>>>>>>> renderer->D
>>>>>>> renderer->a
>>>>>>> renderer->ta
>>>>>>> ());
>>>>>>> Create your own named color (in this case a red with an alpha of 0.5):
>>>>>>> namedColors->GetColor("Red", rgba);
>>>>>>> rgba[3] = 0.5; namedColors->SetColor("My Red", rgba);
>>>>>>>
>>>>>>> Regards
>>>>>>>   Andrew
>>>>>>>
>>>>>>>>
>>>>>>>> ---------- Forwarded message ----------
>>>>>>>> From: Bill Lorensen <bill.lorensen at gmail.com>
>>>>>>>> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>>>>>> Cc: vtkdev <vtk-developers at vtk.org>
>>>>>>>> Bcc:
>>>>>>>> Date: Thu, 22 Jun 2017 13:32:55 -0400
>>>>>>>> Subject: Re: [vtk-developers] vtkNew in examples (or auto?) 
>>>>>>>> Let's leave them as is for now. I want to make sure I understand this.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Jun 22, 2017 at 1:13 PM, Elvis Stansvik 
>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>>> 2017-06-22 19:09 GMT+02:00 Bill Lorensen <bill.lorensen at gmail.com>:
>>>>>>>>>> I'm not sure what you mean by auto-fying
>>>>>>>>>
>>>>>>>>> Sorry, I should have been clearer. What I mean is changing 
>>>>>>>>> declarations such as
>>>>>>>>>
>>>>>>>>>
>>>>>>>> vtkSmartPointer<vtkActor> actor =
>>>>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>>>>>
>>>>>>>>> into
>>>>>>>>>
>>>>>>>>>  auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>>>>>
>>>>>>>>> I think it would cut down on the number of lines in many 
>>>>>>>>> examples, and make them more readable. (This would only be 
>>>>>>>>> done in places where the type of the variable is still clear 
>>>>>>>>> from the declaration.)
>>>>>>>>>
>>>>>>>>> Elvis
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Jun 22, 2017 at 1:07 PM, Elvis Stansvik 
>>>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>>>>> 2017-06-22 19:01 GMT+02:00 Bill Lorensen
>>>>>>>>>>> <bill.lorensen at gmail.com>:
>>>>>>>>>>>> I prefer vtkSmartPointer because it can be used like any 
>>>>>>>>>>>> other vtk pointer. No need for a GetPointer() is some cases.
>>>>>>>>>>>> The example writer is free to use vtkSmartPointer or vtkNew.
>>>>>>>>>>>> But I would leave them as there are.
>>>>>>>>>>>
>>>>>>>>>>> Right, that's a valid point. But how about auto-fying the 
>>>>>>>>>>> declarations? (but keep using vtkSmartPointer)
>>>>>>>>>>>
>>>>>>>>>>> My motivation is that when reading an example, I'm often 
>>>>>>>>>>> squinting to find the variable names in the declarations, 
>>>>>>>>>>> wedged in there somewhere between all those type names and 
>>>>>>>>>>> angle brackets. Especially as the lines are often broken due 
>>>>>>>>>>> to running long.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Other cleanup's sound great. I've also started using 
>>>>>>>>>>>> vtkNamedColors instead of setting float values.
>>>>>>>>>>>
>>>>>>>>>>> Great.
>>>>>>>>>>>
>>>>>>>>>>> Elvis
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Jun 22, 2017 at 12:57 PM, Elvis Stansvik 
>>>>>>>>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>
>>>>>>>>>>>>> How about a refactor of the examples to use vtkNew instead 
>>>>>>>>>>>>> of vtkSmartPointer (where it makes sense)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> E.g.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  vtkNew<vtkActor> actor;
>>>>>>>>>>>>>  actor->SetMapper(mapper);
>>>>>>>>>>>>>
>>>>>>>>>>>>>  vtkNew<vtkRenderer> renderer;  renderer->AddActor(actor);
>>>>>>>>>>>>>
>>>>>>>>>>>>> instead of
>>>>>>>>>>>>>
>>>>>>>>>>>>>  vtkSmartPointer<vtkActor> actor =
>>>>>>>>>>>>>    vtkSmartPointer<vtkActor>::New();
>>>>>>>>>>>>> actor->SetMapper(mapper);
>>>>>>>>>>>>>
>>>>>>>>>>>>>  vtkSmartPointer<vtkRenderer> renderer =
>>>>>>>>>>>>>    vtkSmartPointer<vtkRenderer>::New();
>>>>>>>>>>>>>  renderer->AddActor(actor);
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it would help with the readability of the examples.
>>>>>>>>>>>>> Or are there other reasons for the prevalent use of 
>>>>>>>>>>>>> vtkSmartPointer?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another option would be to use auto, e.g.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  auto actor = vtkSmartPointer<vtkActor>::New();
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, would anyone mind if I did a little naming cleanup, 
>>>>>>>>>>>>> mostly things like "renwin" -> "window" and "iren" -> "interactor"?
>>>>>>>>>>>>> Those
>>>>>>>>>>>>> abbreviations are not that bad, but I think it's better in 
>>>>>>>>>>>>> examples to spell out the variables in proper English.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If there are no objections, I could try to prepare an MR 
>>>>>>>>>>>>> when time permits. If so, vtkNew, or auto?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Elvis
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> Powered by
>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=www.kit
>>>>>>>>>>>>> w
>>>>>>>>>>>>> are.com&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d
>>>>>>>>>>>>> 7 
>>>>>>>>>>>>> f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7
>>>>>>>>>>>>> C 
>>>>>>>>>>>>> 0%7C636338069854146481&sdata=MOVhItfPCXhoqRfpkkpfmBGyNrthS
>>>>>>>>>>>>> Q
>>>>>>>>>>>>> hA9SD%2Fxx0aWHI%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A
>>>>>>>>>>>>> %
>>>>>>>>>>>>> 2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=0
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> %7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6
>>>>>>>>>>>>> 2
>>>>>>>>>>>>> 17%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C6363380698
>>>>>>>>>>>>> 5 
>>>>>>>>>>>>> 4146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6MnSOdAv5BC3HClNEGO
>>>>>>>>>>>>> V
>>>>>>>>>>>>> fY%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Search the list archives at:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A
>>>>>>>>>>>>> % 
>>>>>>>>>>>>> 2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02
>>>>>>>>>>>>> %
>>>>>>>>>>>>> 7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a62
>>>>>>>>>>>>> 1
>>>>>>>>>>>>> 7%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C63633806985
>>>>>>>>>>>>> 4
>>>>>>>>>>>>> 146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOXUHrHWElowi%2B03r
>>>>>>>>>>>>> 3
>>>>>>>>>>>>> OZk%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A
>>>>>>>>>>>>> % 
>>>>>>>>>>>>> 2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-develop
>>>>>>>>>>>>> e
>>>>>>>>>>>>> rs&data=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2
>>>>>>>>>>>>> 8
>>>>>>>>>>>>> 08d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C
>>>>>>>>>>>>> 6 
>>>>>>>>>>>>> 36338069854146481&sdata=Yhue4UpNDB3dlEf0wQYhK7KzsQQES0EEuJ
>>>>>>>>>>>>> W
>>>>>>>>>>>>> VOoG27Zw%3D&reserved=0
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Unpaid intern in BillsBasement at noware dot com
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ___________________________________________
>>>>>>> Andrew J. P. Maclean
>>>>>>>
>>>>>>> ___________________________________________
>>>> _______________________________________________
>>>> Powered by
>>>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&
>>>> d
>>>> a
>>>> ta=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%
>>>> 7
>>>> C
>>>> d61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata
>>>> =
>>>> M
>>>> OVhItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>>>>
>>>> Visit other Kitware open-source projects at 
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>>>> k
>>>> itware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40qu
>>>> e
>>>> e
>>>> nsu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb
>>>> 2
>>>> 8
>>>> 38b925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2
>>>> B
>>>> 6
>>>> MnSOdAv5BC3HClNEGOVfY%3D&reserved=0
>>>>
>>>> Search the list archives at:
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmar
>>>> k
>>>> m
>>>> ail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40que
>>>> e
>>>> n
>>>> su.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2
>>>> 8
>>>> 3
>>>> 8b925c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg
>>>> 6
>>>> S
>>>> OXUHrHWElowi%2B03r3OZk%3D&reserved=0
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>>
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpub
>>>> l
>>>> i
>>>> c.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7C
>>>> l
>>>> a
>>>> sso%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b14
>>>> 2
>>>> d
>>>> 582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlE
>>>> f
>>>> 0
>>>> wQYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>>>>
>>> _______________________________________________
>>> Powered by
>>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&d
>>> a
>>> t
>>> a=02%7C01%7Classo%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7C
>>> d
>>> 6
>>> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=MO
>>> V
>>> h
>>> ItfPCXhoqRfpkkpfmBGyNrthSQhA9SD%2Fxx0aWHI%3D&reserved=0
>>>
>>> Visit other Kitware open-source projects at 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>>> k
>>> i
>>> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40quee
>>> n
>>> s
>>> u.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb283
>>> 8
>>> b
>>> 925c%7C1%7C0%7C636338069854146481&sdata=019a%2BwqJEgmPJZDHThfa%2B6Mn
>>> S
>>> O
>>> dAv5BC3HClNEGOVfY%3D&reserved=0
>>>
>>> Search the list archives at:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmark
>>> m
>>> a
>>> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queen
>>> s
>>> u
>>> .ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d582c4efb2838
>>> b
>>> 9
>>> 25c%7C1%7C0%7C636338069854146481&sdata=4QoQc%2FSmBX0Wscw5TR%2BYg6SOX
>>> U
>>> H
>>> rHWElowi%2B03r3OZk%3D&reserved=0
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpubl
>>> i
>>> c
>>> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Cla
>>> s
>>> so%40queensu.ca%7C0ced79d0c7c54d7f0f2808d4ba1a6217%7Cd61ecb3b38b142d
>>> 5 
>>> 82c4efb2838b925c%7C1%7C0%7C636338069854146481&sdata=Yhue4UpNDB3dlEf0
>>> w
>>> QYhK7KzsQQES0EEuJWVOoG27Zw%3D&reserved=0
>>>
>

From david.lonie at kitware.com  Fri Jun 23 13:50:55 2017
From: david.lonie at kitware.com (David Lonie)
Date: Fri, 23 Jun 2017 13:50:55 -0400
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
Message-ID: <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>

I'm so glad someone brought this up =)

On Fri, Jun 23, 2017 at 10:52 AM, Shawn Waldon <shawn.waldon at kitware.com> wrote:
>  But realistically what it does is
> discourage use of vtkNew.  Most people I talk to say "I would use vtkNew but
> then I have to clutter up my code with GetPointer calls everywhere" and so
> they still use vtkSmartPointer.  Honestly I only used it to clean up
> declarations (the problem discussed earlier in this thread).  Now that we
> can use auto in VTK, I'll probably go back to vtkSmartPointer since it is
> easier to use.

I agree with Shawn. It's an unnecessary hassle to require the Get() to be used.

I suppose I'm just a fan of the design philosophy for C++ about "don't
prevent developers from shooting themselves in the foot." If a dev
doesn't understand VTK's reference counting well enough to understand
that you can't simply return a vtkNew'd pointer without increfing it
first, they're going to have far greater problems using the toolkit
than this.

Besides, you could easily (and safely) return a vtkNew'd pointer from
a function:

vtkObject* function()
{
  vtkNew<vtkObject> obj;
  obj->Register();
  return obj; // If we had implicit conversions, anyway
}

Making the class unwieldly simply so that people don't need to learn
how reference counts work is a poor justification IMO.

Just my 2c,
Dave

From ricardo_morello at hotmail.com  Fri Jun 23 15:33:45 2017
From: ricardo_morello at hotmail.com (Ricardo)
Date: Fri, 23 Jun 2017 12:33:45 -0700 (MST)
Subject: [vtk-developers] OpenVR with DICOM series
Message-ID: <1498246425075-5743763.post@n5.nabble.com>

I've been using VTK with OpenVR for some time now, and I'd like to know how
to reduce a volume size, given a reconstructed series of DICOM. When using
VTK without openvr, the volume seems pretty normal, but when seen through
the glasses, the image gets much bigger.
Thanks!



--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-with-DICOM-series-tp5743763.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From lasso at queensu.ca  Sat Jun 24 09:53:19 2017
From: lasso at queensu.ca (Andras Lasso)
Date: Sat, 24 Jun 2017 13:53:19 +0000
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
 <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>
Message-ID: <BY2PR0701MB19419DA8516C259A195589BCD8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>

Based on the feedbacks and the poll results (11 out of 13 votes for changing current behavior), it seems there is a strong consensus  
for adding implicit conversion.

Here is a pull request with the change:
https://gitlab.kitware.com/vtk/vtk/merge_requests/2961

Andras

-----Original Message-----
From: David Lonie [mailto:david.lonie at kitware.com] 
Sent: Friday, June 23, 2017 1:51 PM
To: Shawn Waldon <shawn.waldon at kitware.com>
Cc: Andras Lasso <lasso at queensu.ca>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21

I'm so glad someone brought this up =)

On Fri, Jun 23, 2017 at 10:52 AM, Shawn Waldon <shawn.waldon at kitware.com> wrote:
>  But realistically what it does is
> discourage use of vtkNew.  Most people I talk to say "I would use 
> vtkNew but then I have to clutter up my code with GetPointer calls 
> everywhere" and so they still use vtkSmartPointer.  Honestly I only 
> used it to clean up declarations (the problem discussed earlier in 
> this thread).  Now that we can use auto in VTK, I'll probably go back 
> to vtkSmartPointer since it is easier to use.

I agree with Shawn. It's an unnecessary hassle to require the Get() to be used.

I suppose I'm just a fan of the design philosophy for C++ about "don't prevent developers from shooting themselves in the foot." If a dev doesn't understand VTK's reference counting well enough to understand that you can't simply return a vtkNew'd pointer without increfing it first, they're going to have far greater problems using the toolkit than this.

Besides, you could easily (and safely) return a vtkNew'd pointer from a function:

vtkObject* function()
{
  vtkNew<vtkObject> obj;
  obj->Register();
  return obj; // If we had implicit conversions, anyway }

Making the class unwieldly simply so that people don't need to learn how reference counts work is a poor justification IMO.

Just my 2c,
Dave

From elvis.stansvik at orexplore.com  Sat Jun 24 12:35:36 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sat, 24 Jun 2017 18:35:36 +0200
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <BY2PR0701MB19419DA8516C259A195589BCD8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
 <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>
 <BY2PR0701MB19419DA8516C259A195589BCD8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
Message-ID: <CAE-7VJnq28r+dDNn=f4GCHCGixHt3EDH5tCLps97c2N_oqyV3g@mail.gmail.com>

2017-06-24 15:53 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
> Based on the feedbacks and the poll results (11 out of 13 votes for changing current behavior), it seems there is a strong consensus
> for adding implicit conversion.

I was away and missed the vote, but frankly I'm not sure what I would
have voted.

Looking at what others do, I guess vtkNew is comparable to
std::unique_ptr or Qt's QScopedPointer, none of which do implicit
conversion to the underlying pointer (they have .get() and .data()
respectively). So VTK would be rather unique in doing that for a
scoped smart pointer I think..

Elvis

>
> Here is a pull request with the change:
> https://gitlab.kitware.com/vtk/vtk/merge_requests/2961
>
> Andras
>
> -----Original Message-----
> From: David Lonie [mailto:david.lonie at kitware.com]
> Sent: Friday, June 23, 2017 1:51 PM
> To: Shawn Waldon <shawn.waldon at kitware.com>
> Cc: Andras Lasso <lasso at queensu.ca>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>
> I'm so glad someone brought this up =)
>
> On Fri, Jun 23, 2017 at 10:52 AM, Shawn Waldon <shawn.waldon at kitware.com> wrote:
>>  But realistically what it does is
>> discourage use of vtkNew.  Most people I talk to say "I would use
>> vtkNew but then I have to clutter up my code with GetPointer calls
>> everywhere" and so they still use vtkSmartPointer.  Honestly I only
>> used it to clean up declarations (the problem discussed earlier in
>> this thread).  Now that we can use auto in VTK, I'll probably go back
>> to vtkSmartPointer since it is easier to use.
>
> I agree with Shawn. It's an unnecessary hassle to require the Get() to be used.
>
> I suppose I'm just a fan of the design philosophy for C++ about "don't prevent developers from shooting themselves in the foot." If a dev doesn't understand VTK's reference counting well enough to understand that you can't simply return a vtkNew'd pointer without increfing it first, they're going to have far greater problems using the toolkit than this.
>
> Besides, you could easily (and safely) return a vtkNew'd pointer from a function:
>
> vtkObject* function()
> {
>   vtkNew<vtkObject> obj;
>   obj->Register();
>   return obj; // If we had implicit conversions, anyway }
>
> Making the class unwieldly simply so that people don't need to learn how reference counts work is a poor justification IMO.
>
> Just my 2c,
> Dave
> _______________________________________________
> 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
>

From lasso at queensu.ca  Sat Jun 24 16:07:01 2017
From: lasso at queensu.ca (Andras Lasso)
Date: Sat, 24 Jun 2017 20:07:01 +0000
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAE-7VJnq28r+dDNn=f4GCHCGixHt3EDH5tCLps97c2N_oqyV3g@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
 <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>
 <BY2PR0701MB19419DA8516C259A195589BCD8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJnq28r+dDNn=f4GCHCGixHt3EDH5tCLps97c2N_oqyV3g@mail.gmail.com>
Message-ID: <BY2PR0701MB19417901903752ABEB42D414D8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>

It is great that you've brought this up! There is a very important, fundamental difference. Unlike std::shared_ptr or QSharedPointer, VTK smart pointer does NOT need clear distinction between the pointer object and the raw pointer it holds, because reference counting is implemented in the managed object itself.

See in std::shared_ptr documentation: "Constructing a new shared_ptr using the raw underlying pointer owned by another shared_ptr leads to undefined behavior." (http://en.cppreference.com/w/cpp/memory/shared_ptr)

In VTK, if you assign a vtkSmartPointer to another, internally the raw pointer is retrieved and used (Common/Core/vtkSmartPointer.h):

  vtkSmartPointer& operator=(const vtkSmartPointer<U>& r)
  {
    this->vtkSmartPointerBase::operator=(CheckType(r.GetPointer()));
    return *this;
  }

VTK smart pointers work differently from STL and Qt, so it is reasonable to use a different API that reflects this difference. As VTK allows safe use of a simpler API, we should take advantage of that and use it.

Andras

-----Original Message-----
From: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com] 
Sent: Saturday, June 24, 2017 12:36 PM
To: Andras Lasso <lasso at queensu.ca>
Cc: David Lonie <david.lonie at kitware.com>; Shawn Waldon <shawn.waldon at kitware.com>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21

2017-06-24 15:53 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
> Based on the feedbacks and the poll results (11 out of 13 votes for 
> changing current behavior), it seems there is a strong consensus for adding implicit conversion.

I was away and missed the vote, but frankly I'm not sure what I would have voted.

Looking at what others do, I guess vtkNew is comparable to std::unique_ptr or Qt's QScopedPointer, none of which do implicit conversion to the underlying pointer (they have .get() and .data() respectively). So VTK would be rather unique in doing that for a scoped smart pointer I think..

Elvis

>
> Here is a pull request with the change:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> b.kitware.com%2Fvtk%2Fvtk%2Fmerge_requests%2F2961&data=02%7C01%7Classo
> %40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c
> 4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=2Jv0QS1qlRUgSJvN%2BO8
> 0pXOt89kKC0NP7iXXRr2mg30%3D&reserved=0
>
> Andras
>
> -----Original Message-----
> From: David Lonie [mailto:david.lonie at kitware.com]
> Sent: Friday, June 23, 2017 1:51 PM
> To: Shawn Waldon <shawn.waldon at kitware.com>
> Cc: Andras Lasso <lasso at queensu.ca>; VTK Developers 
> <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>
> I'm so glad someone brought this up =)
>
> On Fri, Jun 23, 2017 at 10:52 AM, Shawn Waldon <shawn.waldon at kitware.com> wrote:
>>  But realistically what it does is
>> discourage use of vtkNew.  Most people I talk to say "I would use 
>> vtkNew but then I have to clutter up my code with GetPointer calls 
>> everywhere" and so they still use vtkSmartPointer.  Honestly I only 
>> used it to clean up declarations (the problem discussed earlier in 
>> this thread).  Now that we can use auto in VTK, I'll probably go back 
>> to vtkSmartPointer since it is easier to use.
>
> I agree with Shawn. It's an unnecessary hassle to require the Get() to be used.
>
> I suppose I'm just a fan of the design philosophy for C++ about "don't prevent developers from shooting themselves in the foot." If a dev doesn't understand VTK's reference counting well enough to understand that you can't simply return a vtkNew'd pointer without increfing it first, they're going to have far greater problems using the toolkit than this.
>
> Besides, you could easily (and safely) return a vtkNew'd pointer from a function:
>
> vtkObject* function()
> {
>   vtkNew<vtkObject> obj;
>   obj->Register();
>   return obj; // If we had implicit conversions, anyway }
>
> Making the class unwieldly simply so that people don't need to learn how reference counts work is a poor justification IMO.
>
> Just my 2c,
> Dave
> _______________________________________________
> Powered by 
> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&dat
> a=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd6
> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=EWly
> 8qDaOVuCYOrDhoQ7SyY3glwTdlm1J1nxY%2BBDO50%3D&reserved=0
>
> Visit other Kitware open-source projects at 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki
> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queens
> u.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b
> 925c%7C1%7C0%7C636339189405346369&sdata=v7U9kMfdmgpWZ6WYn1nyPTuUHWzn4s
> J6XvYEJdpw50I%3D&reserved=0
>
> Search the list archives at: 
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkma
> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu
> .ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b9
> 25c%7C1%7C0%7C636339189405346369&sdata=otfBLrSAA5d7a9u6mrb56%2ByrIVM%2
> Bl3f%2BZNQpwOvqgO0%3D&reserved=0
>
> Follow this link to subscribe/unsubscribe:
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic
> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=whCFetn1LnPSRi0CZ%2BD1aGlMHqdv5vSgzkRdcuLw8qI%3D&reserved=0
>

From andrew.amaclean at gmail.com  Sat Jun 24 19:18:16 2017
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sun, 25 Jun 2017 09:18:16 +1000
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <BY2PR0701MB19417901903752ABEB42D414D8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
 <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>
 <BY2PR0701MB19419DA8516C259A195589BCD8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJnq28r+dDNn=f4GCHCGixHt3EDH5tCLps97c2N_oqyV3g@mail.gmail.com>
 <BY2PR0701MB19417901903752ABEB42D414D8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
Message-ID: <CAHDsG9MUj5PMNp=t2kXqf3X0q-uapVDzujQs_HPM-Aq_DggHig@mail.gmail.com>

Hi Andras,

One thing that may be relevant is this link:
http://marc.info/?l=vtk-developers&m=126471789304821
Note: I think
vtkSmartPointer<vtkPolyData> output;
should be:
vtkSmartPointer<vtkPolyData> readerOutput;

I think the example there nicely demonstrates the difference between vtkNew
and vtkSmartPointer.

Maybe something like this could be incorporated into the testing in
https://gitlab.kitware.com/vtk/vtk/merge_requests/2961

Regards
   Andrew

On Sun, Jun 25, 2017 at 6:07 AM, Andras Lasso <lasso at queensu.ca> wrote:

> It is great that you've brought this up! There is a very important,
> fundamental difference. Unlike std::shared_ptr or QSharedPointer, VTK smart
> pointer does NOT need clear distinction between the pointer object and the
> raw pointer it holds, because reference counting is implemented in the
> managed object itself.
>
> See in std::shared_ptr documentation: "Constructing a new shared_ptr using
> the raw underlying pointer owned by another shared_ptr leads to undefined
> behavior." (http://en.cppreference.com/w/cpp/memory/shared_ptr)
>
> In VTK, if you assign a vtkSmartPointer to another, internally the raw
> pointer is retrieved and used (Common/Core/vtkSmartPointer.h):
>
>   vtkSmartPointer& operator=(const vtkSmartPointer<U>& r)
>   {
>     this->vtkSmartPointerBase::operator=(CheckType(r.GetPointer()));
>     return *this;
>   }
>
> VTK smart pointers work differently from STL and Qt, so it is reasonable
> to use a different API that reflects this difference. As VTK allows safe
> use of a simpler API, we should take advantage of that and use it.
>
> Andras
>
> -----Original Message-----
> From: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com]
> Sent: Saturday, June 24, 2017 12:36 PM
> To: Andras Lasso <lasso at queensu.ca>
> Cc: David Lonie <david.lonie at kitware.com>; Shawn Waldon <
> shawn.waldon at kitware.com>; VTK Developers <vtk-developers at vtk.org>;
> Andrew Maclean <andrew.amaclean at gmail.com>
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>
> 2017-06-24 15:53 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
> > Based on the feedbacks and the poll results (11 out of 13 votes for
> > changing current behavior), it seems there is a strong consensus for
> adding implicit conversion.
>
> I was away and missed the vote, but frankly I'm not sure what I would have
> voted.
>
> Looking at what others do, I guess vtkNew is comparable to std::unique_ptr
> or Qt's QScopedPointer, none of which do implicit conversion to the
> underlying pointer (they have .get() and .data() respectively). So VTK
> would be rather unique in doing that for a scoped smart pointer I think..
>
> Elvis
>
> >
> > Here is a pull request with the change:
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> > b.kitware.com%2Fvtk%2Fvtk%2Fmerge_requests%2F2961&data=02%7C01%7Classo
> > %40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c
> > 4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=2Jv0QS1qlRUgSJvN%2BO8
> > 0pXOt89kKC0NP7iXXRr2mg30%3D&reserved=0
> >
> > Andras
> >
> > -----Original Message-----
> > From: David Lonie [mailto:david.lonie at kitware.com]
> > Sent: Friday, June 23, 2017 1:51 PM
> > To: Shawn Waldon <shawn.waldon at kitware.com>
> > Cc: Andras Lasso <lasso at queensu.ca>; VTK Developers
> > <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
> > Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
> >
> > I'm so glad someone brought this up =)
> >
> > On Fri, Jun 23, 2017 at 10:52 AM, Shawn Waldon <shawn.waldon at kitware.com>
> wrote:
> >>  But realistically what it does is
> >> discourage use of vtkNew.  Most people I talk to say "I would use
> >> vtkNew but then I have to clutter up my code with GetPointer calls
> >> everywhere" and so they still use vtkSmartPointer.  Honestly I only
> >> used it to clean up declarations (the problem discussed earlier in
> >> this thread).  Now that we can use auto in VTK, I'll probably go back
> >> to vtkSmartPointer since it is easier to use.
> >
> > I agree with Shawn. It's an unnecessary hassle to require the Get() to
> be used.
> >
> > I suppose I'm just a fan of the design philosophy for C++ about "don't
> prevent developers from shooting themselves in the foot." If a dev doesn't
> understand VTK's reference counting well enough to understand that you
> can't simply return a vtkNew'd pointer without increfing it first, they're
> going to have far greater problems using the toolkit than this.
> >
> > Besides, you could easily (and safely) return a vtkNew'd pointer from a
> function:
> >
> > vtkObject* function()
> > {
> >   vtkNew<vtkObject> obj;
> >   obj->Register();
> >   return obj; // If we had implicit conversions, anyway }
> >
> > Making the class unwieldly simply so that people don't need to learn how
> reference counts work is a poor justification IMO.
> >
> > Just my 2c,
> > Dave
> > _______________________________________________
> > Powered by
> > https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&dat
> > a=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd6
> > 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=EWly
> > 8qDaOVuCYOrDhoQ7SyY3glwTdlm1J1nxY%2BBDO50%3D&reserved=0
> >
> > Visit other Kitware open-source projects at
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki
> > tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queens
> > u.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b
> > 925c%7C1%7C0%7C636339189405346369&sdata=v7U9kMfdmgpWZ6WYn1nyPTuUHWzn4s
> > J6XvYEJdpw50I%3D&reserved=0
> >
> > Search the list archives at:
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkma
> > il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu
> > .ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b9
> > 25c%7C1%7C0%7C636339189405346369&sdata=otfBLrSAA5d7a9u6mrb56%2ByrIVM%2
> > Bl3f%2BZNQpwOvqgO0%3D&reserved=0
> >
> > Follow this link to subscribe/unsubscribe:
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic
> > .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%
> 40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%
> 7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=
> whCFetn1LnPSRi0CZ%2BD1aGlMHqdv5vSgzkRdcuLw8qI%3D&reserved=0
> >
>



-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170625/314d17ac/attachment-0001.html>

From elvis.stansvik at orexplore.com  Sun Jun 25 04:27:50 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sun, 25 Jun 2017 10:27:50 +0200
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <BY2PR0701MB19417901903752ABEB42D414D8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
 <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>
 <BY2PR0701MB19419DA8516C259A195589BCD8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJnq28r+dDNn=f4GCHCGixHt3EDH5tCLps97c2N_oqyV3g@mail.gmail.com>
 <BY2PR0701MB19417901903752ABEB42D414D8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
Message-ID: <CAE-7VJ=65URUp2eZi2USNvaUu0HfeVgk7g6VLFu29LuOeMoZJg@mail.gmail.com>

2017-06-24 22:07 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
> It is great that you've brought this up! There is a very important, fundamental difference. Unlike std::shared_ptr or QSharedPointer, VTK smart pointer does NOT need clear distinction between the pointer object and the raw pointer it holds, because reference counting is implemented in the managed object itself.
>
> See in std::shared_ptr documentation: "Constructing a new shared_ptr using the raw underlying pointer owned by another shared_ptr leads to undefined behavior." (http://en.cppreference.com/w/cpp/memory/shared_ptr)
>
> In VTK, if you assign a vtkSmartPointer to another, internally the raw pointer is retrieved and used (Common/Core/vtkSmartPointer.h):
>
>   vtkSmartPointer& operator=(const vtkSmartPointer<U>& r)
>   {
>     this->vtkSmartPointerBase::operator=(CheckType(r.GetPointer()));
>     return *this;
>   }
>
> VTK smart pointers work differently from STL and Qt, so it is reasonable to use a different API that reflects this difference. As VTK allows safe use of a simpler API, we should take advantage of that and use it.

That's a good point, and an important difference.

Though, it's still unsafe (of course) in VTK to do say (pseudo):

struct MyClass {
    void setArray(vtkDataArray *arr) { a = arr; }
    void doSomething() { /* Use the a member here */ }

    vtkDataArray *a;
}

and then

MyClass c;

{ // some scope somewhere
    vtkNew<vtkDataArray> a;
    ...
    c.func(a);
} // a dies (internal pointer freed), c survives

c.doSomething(); // oops

But I guess this should be filed in the 'so stupid the user should not
be "protected" from it by a slightly awkward .Get()' category.

I think you have my vote to add implicit conversion as well.

Elvis

>
> Andras
>
> -----Original Message-----
> From: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com]
> Sent: Saturday, June 24, 2017 12:36 PM
> To: Andras Lasso <lasso at queensu.ca>
> Cc: David Lonie <david.lonie at kitware.com>; Shawn Waldon <shawn.waldon at kitware.com>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>
> 2017-06-24 15:53 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
>> Based on the feedbacks and the poll results (11 out of 13 votes for
>> changing current behavior), it seems there is a strong consensus for adding implicit conversion.
>
> I was away and missed the vote, but frankly I'm not sure what I would have voted.
>
> Looking at what others do, I guess vtkNew is comparable to std::unique_ptr or Qt's QScopedPointer, none of which do implicit conversion to the underlying pointer (they have .get() and .data() respectively). So VTK would be rather unique in doing that for a scoped smart pointer I think..
>
> Elvis
>
>>
>> Here is a pull request with the change:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
>> b.kitware.com%2Fvtk%2Fvtk%2Fmerge_requests%2F2961&data=02%7C01%7Classo
>> %40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c
>> 4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=2Jv0QS1qlRUgSJvN%2BO8
>> 0pXOt89kKC0NP7iXXRr2mg30%3D&reserved=0
>>
>> Andras
>>
>> -----Original Message-----
>> From: David Lonie [mailto:david.lonie at kitware.com]
>> Sent: Friday, June 23, 2017 1:51 PM
>> To: Shawn Waldon <shawn.waldon at kitware.com>
>> Cc: Andras Lasso <lasso at queensu.ca>; VTK Developers
>> <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>>
>> I'm so glad someone brought this up =)
>>
>> On Fri, Jun 23, 2017 at 10:52 AM, Shawn Waldon <shawn.waldon at kitware.com> wrote:
>>>  But realistically what it does is
>>> discourage use of vtkNew.  Most people I talk to say "I would use
>>> vtkNew but then I have to clutter up my code with GetPointer calls
>>> everywhere" and so they still use vtkSmartPointer.  Honestly I only
>>> used it to clean up declarations (the problem discussed earlier in
>>> this thread).  Now that we can use auto in VTK, I'll probably go back
>>> to vtkSmartPointer since it is easier to use.
>>
>> I agree with Shawn. It's an unnecessary hassle to require the Get() to be used.
>>
>> I suppose I'm just a fan of the design philosophy for C++ about "don't prevent developers from shooting themselves in the foot." If a dev doesn't understand VTK's reference counting well enough to understand that you can't simply return a vtkNew'd pointer without increfing it first, they're going to have far greater problems using the toolkit than this.
>>
>> Besides, you could easily (and safely) return a vtkNew'd pointer from a function:
>>
>> vtkObject* function()
>> {
>>   vtkNew<vtkObject> obj;
>>   obj->Register();
>>   return obj; // If we had implicit conversions, anyway }
>>
>> Making the class unwieldly simply so that people don't need to learn how reference counts work is a poor justification IMO.
>>
>> Just my 2c,
>> Dave
>> _______________________________________________
>> Powered by
>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&dat
>> a=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd6
>> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=EWly
>> 8qDaOVuCYOrDhoQ7SyY3glwTdlm1J1nxY%2BBDO50%3D&reserved=0
>>
>> Visit other Kitware open-source projects at
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki
>> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queens
>> u.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b
>> 925c%7C1%7C0%7C636339189405346369&sdata=v7U9kMfdmgpWZ6WYn1nyPTuUHWzn4s
>> J6XvYEJdpw50I%3D&reserved=0
>>
>> Search the list archives at:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkma
>> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu
>> .ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b9
>> 25c%7C1%7C0%7C636339189405346369&sdata=otfBLrSAA5d7a9u6mrb56%2ByrIVM%2
>> Bl3f%2BZNQpwOvqgO0%3D&reserved=0
>>
>> Follow this link to subscribe/unsubscribe:
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic
>> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=whCFetn1LnPSRi0CZ%2BD1aGlMHqdv5vSgzkRdcuLw8qI%3D&reserved=0
>>

From elvis.stansvik at orexplore.com  Sun Jun 25 04:30:21 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sun, 25 Jun 2017 10:30:21 +0200
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAE-7VJ=65URUp2eZi2USNvaUu0HfeVgk7g6VLFu29LuOeMoZJg@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
 <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>
 <BY2PR0701MB19419DA8516C259A195589BCD8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJnq28r+dDNn=f4GCHCGixHt3EDH5tCLps97c2N_oqyV3g@mail.gmail.com>
 <BY2PR0701MB19417901903752ABEB42D414D8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJ=65URUp2eZi2USNvaUu0HfeVgk7g6VLFu29LuOeMoZJg@mail.gmail.com>
Message-ID: <CAE-7VJnAg6EcoVZsTSgtQm=Xg=WEpOUPiojxBceou0yCLFOJbA@mail.gmail.com>

2017-06-25 10:27 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> 2017-06-24 22:07 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
>> It is great that you've brought this up! There is a very important, fundamental difference. Unlike std::shared_ptr or QSharedPointer, VTK smart pointer does NOT need clear distinction between the pointer object and the raw pointer it holds, because reference counting is implemented in the managed object itself.
>>
>> See in std::shared_ptr documentation: "Constructing a new shared_ptr using the raw underlying pointer owned by another shared_ptr leads to undefined behavior." (http://en.cppreference.com/w/cpp/memory/shared_ptr)
>>
>> In VTK, if you assign a vtkSmartPointer to another, internally the raw pointer is retrieved and used (Common/Core/vtkSmartPointer.h):
>>
>>   vtkSmartPointer& operator=(const vtkSmartPointer<U>& r)
>>   {
>>     this->vtkSmartPointerBase::operator=(CheckType(r.GetPointer()));
>>     return *this;
>>   }
>>
>> VTK smart pointers work differently from STL and Qt, so it is reasonable to use a different API that reflects this difference. As VTK allows safe use of a simpler API, we should take advantage of that and use it.
>
> That's a good point, and an important difference.
>
> Though, it's still unsafe (of course) in VTK to do say (pseudo):
>
> struct MyClass {
>     void setArray(vtkDataArray *arr) { a = arr; }
>     void doSomething() { /* Use the a member here */ }
>
>     vtkDataArray *a;
> }
>
> and then
>
> MyClass c;
>
> { // some scope somewhere
>     vtkNew<vtkDataArray> a;
>     ...
>     c.func(a);

I meant setArray(a) here of course.

Elvis

> } // a dies (internal pointer freed), c survives
>
> c.doSomething(); // oops
>
> But I guess this should be filed in the 'so stupid the user should not
> be "protected" from it by a slightly awkward .Get()' category.
>
> I think you have my vote to add implicit conversion as well.
>
> Elvis
>
>>
>> Andras
>>
>> -----Original Message-----
>> From: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com]
>> Sent: Saturday, June 24, 2017 12:36 PM
>> To: Andras Lasso <lasso at queensu.ca>
>> Cc: David Lonie <david.lonie at kitware.com>; Shawn Waldon <shawn.waldon at kitware.com>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>>
>> 2017-06-24 15:53 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
>>> Based on the feedbacks and the poll results (11 out of 13 votes for
>>> changing current behavior), it seems there is a strong consensus for adding implicit conversion.
>>
>> I was away and missed the vote, but frankly I'm not sure what I would have voted.
>>
>> Looking at what others do, I guess vtkNew is comparable to std::unique_ptr or Qt's QScopedPointer, none of which do implicit conversion to the underlying pointer (they have .get() and .data() respectively). So VTK would be rather unique in doing that for a scoped smart pointer I think..
>>
>> Elvis
>>
>>>
>>> Here is a pull request with the change:
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
>>> b.kitware.com%2Fvtk%2Fvtk%2Fmerge_requests%2F2961&data=02%7C01%7Classo
>>> %40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c
>>> 4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=2Jv0QS1qlRUgSJvN%2BO8
>>> 0pXOt89kKC0NP7iXXRr2mg30%3D&reserved=0
>>>
>>> Andras
>>>
>>> -----Original Message-----
>>> From: David Lonie [mailto:david.lonie at kitware.com]
>>> Sent: Friday, June 23, 2017 1:51 PM
>>> To: Shawn Waldon <shawn.waldon at kitware.com>
>>> Cc: Andras Lasso <lasso at queensu.ca>; VTK Developers
>>> <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
>>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>>>
>>> I'm so glad someone brought this up =)
>>>
>>> On Fri, Jun 23, 2017 at 10:52 AM, Shawn Waldon <shawn.waldon at kitware.com> wrote:
>>>>  But realistically what it does is
>>>> discourage use of vtkNew.  Most people I talk to say "I would use
>>>> vtkNew but then I have to clutter up my code with GetPointer calls
>>>> everywhere" and so they still use vtkSmartPointer.  Honestly I only
>>>> used it to clean up declarations (the problem discussed earlier in
>>>> this thread).  Now that we can use auto in VTK, I'll probably go back
>>>> to vtkSmartPointer since it is easier to use.
>>>
>>> I agree with Shawn. It's an unnecessary hassle to require the Get() to be used.
>>>
>>> I suppose I'm just a fan of the design philosophy for C++ about "don't prevent developers from shooting themselves in the foot." If a dev doesn't understand VTK's reference counting well enough to understand that you can't simply return a vtkNew'd pointer without increfing it first, they're going to have far greater problems using the toolkit than this.
>>>
>>> Besides, you could easily (and safely) return a vtkNew'd pointer from a function:
>>>
>>> vtkObject* function()
>>> {
>>>   vtkNew<vtkObject> obj;
>>>   obj->Register();
>>>   return obj; // If we had implicit conversions, anyway }
>>>
>>> Making the class unwieldly simply so that people don't need to learn how reference counts work is a poor justification IMO.
>>>
>>> Just my 2c,
>>> Dave
>>> _______________________________________________
>>> Powered by
>>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&dat
>>> a=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd6
>>> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=EWly
>>> 8qDaOVuCYOrDhoQ7SyY3glwTdlm1J1nxY%2BBDO50%3D&reserved=0
>>>
>>> Visit other Kitware open-source projects at
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki
>>> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queens
>>> u.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b
>>> 925c%7C1%7C0%7C636339189405346369&sdata=v7U9kMfdmgpWZ6WYn1nyPTuUHWzn4s
>>> J6XvYEJdpw50I%3D&reserved=0
>>>
>>> Search the list archives at:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkma
>>> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu
>>> .ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b9
>>> 25c%7C1%7C0%7C636339189405346369&sdata=otfBLrSAA5d7a9u6mrb56%2ByrIVM%2
>>> Bl3f%2BZNQpwOvqgO0%3D&reserved=0
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic
>>> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=whCFetn1LnPSRi0CZ%2BD1aGlMHqdv5vSgzkRdcuLw8qI%3D&reserved=0
>>>

From elvis.stansvik at orexplore.com  Sun Jun 25 04:43:42 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sun, 25 Jun 2017 10:43:42 +0200
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAE-7VJ=65URUp2eZi2USNvaUu0HfeVgk7g6VLFu29LuOeMoZJg@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
 <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>
 <BY2PR0701MB19419DA8516C259A195589BCD8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJnq28r+dDNn=f4GCHCGixHt3EDH5tCLps97c2N_oqyV3g@mail.gmail.com>
 <BY2PR0701MB19417901903752ABEB42D414D8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJ=65URUp2eZi2USNvaUu0HfeVgk7g6VLFu29LuOeMoZJg@mail.gmail.com>
Message-ID: <CAE-7VJ=mvm2zOrOOe6f7YU7Rr-UmjASgFeFzF_K7M2gcQDokvg@mail.gmail.com>

But, going back to my original proposal now.

1. Using auto -> not a good idea since people may want to compile with
older compilers
2. Using vtkNew -> not a good idea since all the .Get() / .GetPointer() are ugly
3. Tidying up variable names (e.g. "iren", "renWin", ...) -> I got
some opposition to that too

So I guess I'll hold off on doing anything for now.

Though re. 1, what compilers don't support C++11 nowadays? I
personally think that would be sufficiently rare at this point that
those users could adapt the examples to fit their old compiler.

But I guess the bigger question is whether the examples should be
curated at all, or always left intact, to not discourage contribution?

Elvis

2017-06-25 10:27 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> 2017-06-24 22:07 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
>> It is great that you've brought this up! There is a very important, fundamental difference. Unlike std::shared_ptr or QSharedPointer, VTK smart pointer does NOT need clear distinction between the pointer object and the raw pointer it holds, because reference counting is implemented in the managed object itself.
>>
>> See in std::shared_ptr documentation: "Constructing a new shared_ptr using the raw underlying pointer owned by another shared_ptr leads to undefined behavior." (http://en.cppreference.com/w/cpp/memory/shared_ptr)
>>
>> In VTK, if you assign a vtkSmartPointer to another, internally the raw pointer is retrieved and used (Common/Core/vtkSmartPointer.h):
>>
>>   vtkSmartPointer& operator=(const vtkSmartPointer<U>& r)
>>   {
>>     this->vtkSmartPointerBase::operator=(CheckType(r.GetPointer()));
>>     return *this;
>>   }
>>
>> VTK smart pointers work differently from STL and Qt, so it is reasonable to use a different API that reflects this difference. As VTK allows safe use of a simpler API, we should take advantage of that and use it.
>
> That's a good point, and an important difference.
>
> Though, it's still unsafe (of course) in VTK to do say (pseudo):
>
> struct MyClass {
>     void setArray(vtkDataArray *arr) { a = arr; }
>     void doSomething() { /* Use the a member here */ }
>
>     vtkDataArray *a;
> }
>
> and then
>
> MyClass c;
>
> { // some scope somewhere
>     vtkNew<vtkDataArray> a;
>     ...
>     c.func(a);
> } // a dies (internal pointer freed), c survives
>
> c.doSomething(); // oops
>
> But I guess this should be filed in the 'so stupid the user should not
> be "protected" from it by a slightly awkward .Get()' category.
>
> I think you have my vote to add implicit conversion as well.
>
> Elvis
>
>>
>> Andras
>>
>> -----Original Message-----
>> From: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com]
>> Sent: Saturday, June 24, 2017 12:36 PM
>> To: Andras Lasso <lasso at queensu.ca>
>> Cc: David Lonie <david.lonie at kitware.com>; Shawn Waldon <shawn.waldon at kitware.com>; VTK Developers <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>>
>> 2017-06-24 15:53 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
>>> Based on the feedbacks and the poll results (11 out of 13 votes for
>>> changing current behavior), it seems there is a strong consensus for adding implicit conversion.
>>
>> I was away and missed the vote, but frankly I'm not sure what I would have voted.
>>
>> Looking at what others do, I guess vtkNew is comparable to std::unique_ptr or Qt's QScopedPointer, none of which do implicit conversion to the underlying pointer (they have .get() and .data() respectively). So VTK would be rather unique in doing that for a scoped smart pointer I think..
>>
>> Elvis
>>
>>>
>>> Here is a pull request with the change:
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
>>> b.kitware.com%2Fvtk%2Fvtk%2Fmerge_requests%2F2961&data=02%7C01%7Classo
>>> %40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c
>>> 4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=2Jv0QS1qlRUgSJvN%2BO8
>>> 0pXOt89kKC0NP7iXXRr2mg30%3D&reserved=0
>>>
>>> Andras
>>>
>>> -----Original Message-----
>>> From: David Lonie [mailto:david.lonie at kitware.com]
>>> Sent: Friday, June 23, 2017 1:51 PM
>>> To: Shawn Waldon <shawn.waldon at kitware.com>
>>> Cc: Andras Lasso <lasso at queensu.ca>; VTK Developers
>>> <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
>>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>>>
>>> I'm so glad someone brought this up =)
>>>
>>> On Fri, Jun 23, 2017 at 10:52 AM, Shawn Waldon <shawn.waldon at kitware.com> wrote:
>>>>  But realistically what it does is
>>>> discourage use of vtkNew.  Most people I talk to say "I would use
>>>> vtkNew but then I have to clutter up my code with GetPointer calls
>>>> everywhere" and so they still use vtkSmartPointer.  Honestly I only
>>>> used it to clean up declarations (the problem discussed earlier in
>>>> this thread).  Now that we can use auto in VTK, I'll probably go back
>>>> to vtkSmartPointer since it is easier to use.
>>>
>>> I agree with Shawn. It's an unnecessary hassle to require the Get() to be used.
>>>
>>> I suppose I'm just a fan of the design philosophy for C++ about "don't prevent developers from shooting themselves in the foot." If a dev doesn't understand VTK's reference counting well enough to understand that you can't simply return a vtkNew'd pointer without increfing it first, they're going to have far greater problems using the toolkit than this.
>>>
>>> Besides, you could easily (and safely) return a vtkNew'd pointer from a function:
>>>
>>> vtkObject* function()
>>> {
>>>   vtkNew<vtkObject> obj;
>>>   obj->Register();
>>>   return obj; // If we had implicit conversions, anyway }
>>>
>>> Making the class unwieldly simply so that people don't need to learn how reference counts work is a poor justification IMO.
>>>
>>> Just my 2c,
>>> Dave
>>> _______________________________________________
>>> Powered by
>>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&dat
>>> a=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd6
>>> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=EWly
>>> 8qDaOVuCYOrDhoQ7SyY3glwTdlm1J1nxY%2BBDO50%3D&reserved=0
>>>
>>> Visit other Kitware open-source projects at
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki
>>> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queens
>>> u.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b
>>> 925c%7C1%7C0%7C636339189405346369&sdata=v7U9kMfdmgpWZ6WYn1nyPTuUHWzn4s
>>> J6XvYEJdpw50I%3D&reserved=0
>>>
>>> Search the list archives at:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkma
>>> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu
>>> .ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b9
>>> 25c%7C1%7C0%7C636339189405346369&sdata=otfBLrSAA5d7a9u6mrb56%2ByrIVM%2
>>> Bl3f%2BZNQpwOvqgO0%3D&reserved=0
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic
>>> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=whCFetn1LnPSRi0CZ%2BD1aGlMHqdv5vSgzkRdcuLw8qI%3D&reserved=0
>>>

From andrew.amaclean at gmail.com  Sun Jun 25 05:13:32 2017
From: andrew.amaclean at gmail.com (Andrew Maclean)
Date: Sun, 25 Jun 2017 19:13:32 +1000
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAE-7VJ=mvm2zOrOOe6f7YU7Rr-UmjASgFeFzF_K7M2gcQDokvg@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
 <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>
 <BY2PR0701MB19419DA8516C259A195589BCD8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJnq28r+dDNn=f4GCHCGixHt3EDH5tCLps97c2N_oqyV3g@mail.gmail.com>
 <BY2PR0701MB19417901903752ABEB42D414D8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJ=65URUp2eZi2USNvaUu0HfeVgk7g6VLFu29LuOeMoZJg@mail.gmail.com>
 <CAE-7VJ=mvm2zOrOOe6f7YU7Rr-UmjASgFeFzF_K7M2gcQDokvg@mail.gmail.com>
Message-ID: <CAHDsG9NfD5Cznin09LUKXwrMVFFeUFsU7XeMMYo8RKU6VS5nLw@mail.gmail.com>

This table may be useful to see what features are supported:
http://en.cppreference.com/w/cpp/compiler_support

Please also remember that we need to ensure that the VTK7.x series are also
supported, not just VTK8+.

Personally I have no problems with new submissions using C++11 features.

Andrew Maclean

On 25 Jun 2017 18:43, "Elvis Stansvik" <elvis.stansvik at orexplore.com> wrote:

> But, going back to my original proposal now.
>
> 1. Using auto -> not a good idea since people may want to compile with
> older compilers
> 2. Using vtkNew -> not a good idea since all the .Get() / .GetPointer()
> are ugly
> 3. Tidying up variable names (e.g. "iren", "renWin", ...) -> I got
> some opposition to that too
>
> So I guess I'll hold off on doing anything for now.
>
> Though re. 1, what compilers don't support C++11 nowadays? I
> personally think that would be sufficiently rare at this point that
> those users could adapt the examples to fit their old compiler.
>
> But I guess the bigger question is whether the examples should be
> curated at all, or always left intact, to not discourage contribution?
>
> Elvis
>
> 2017-06-25 10:27 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> > 2017-06-24 22:07 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
> >> It is great that you've brought this up! There is a very important,
> fundamental difference. Unlike std::shared_ptr or QSharedPointer, VTK smart
> pointer does NOT need clear distinction between the pointer object and the
> raw pointer it holds, because reference counting is implemented in the
> managed object itself.
> >>
> >> See in std::shared_ptr documentation: "Constructing a new shared_ptr
> using the raw underlying pointer owned by another shared_ptr leads to
> undefined behavior." (http://en.cppreference.com/w/cpp/memory/shared_ptr)
> >>
> >> In VTK, if you assign a vtkSmartPointer to another, internally the raw
> pointer is retrieved and used (Common/Core/vtkSmartPointer.h):
> >>
> >>   vtkSmartPointer& operator=(const vtkSmartPointer<U>& r)
> >>   {
> >>     this->vtkSmartPointerBase::operator=(CheckType(r.GetPointer()));
> >>     return *this;
> >>   }
> >>
> >> VTK smart pointers work differently from STL and Qt, so it is
> reasonable to use a different API that reflects this difference. As VTK
> allows safe use of a simpler API, we should take advantage of that and use
> it.
> >
> > That's a good point, and an important difference.
> >
> > Though, it's still unsafe (of course) in VTK to do say (pseudo):
> >
> > struct MyClass {
> >     void setArray(vtkDataArray *arr) { a = arr; }
> >     void doSomething() { /* Use the a member here */ }
> >
> >     vtkDataArray *a;
> > }
> >
> > and then
> >
> > MyClass c;
> >
> > { // some scope somewhere
> >     vtkNew<vtkDataArray> a;
> >     ...
> >     c.func(a);
> > } // a dies (internal pointer freed), c survives
> >
> > c.doSomething(); // oops
> >
> > But I guess this should be filed in the 'so stupid the user should not
> > be "protected" from it by a slightly awkward .Get()' category.
> >
> > I think you have my vote to add implicit conversion as well.
> >
> > Elvis
> >
> >>
> >> Andras
> >>
> >> -----Original Message-----
> >> From: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com]
> >> Sent: Saturday, June 24, 2017 12:36 PM
> >> To: Andras Lasso <lasso at queensu.ca>
> >> Cc: David Lonie <david.lonie at kitware.com>; Shawn Waldon <
> shawn.waldon at kitware.com>; VTK Developers <vtk-developers at vtk.org>;
> Andrew Maclean <andrew.amaclean at gmail.com>
> >> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
> >>
> >> 2017-06-24 15:53 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
> >>> Based on the feedbacks and the poll results (11 out of 13 votes for
> >>> changing current behavior), it seems there is a strong consensus for
> adding implicit conversion.
> >>
> >> I was away and missed the vote, but frankly I'm not sure what I would
> have voted.
> >>
> >> Looking at what others do, I guess vtkNew is comparable to
> std::unique_ptr or Qt's QScopedPointer, none of which do implicit
> conversion to the underlying pointer (they have .get() and .data()
> respectively). So VTK would be rather unique in doing that for a scoped
> smart pointer I think..
> >>
> >> Elvis
> >>
> >>>
> >>> Here is a pull request with the change:
> >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> >>> b.kitware.com%2Fvtk%2Fvtk%2Fmerge_requests%2F2961&data=02%7C01%7Classo
> >>> %40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c
> >>> 4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=2Jv0QS1qlRUgSJvN%2BO8
> >>> 0pXOt89kKC0NP7iXXRr2mg30%3D&reserved=0
> >>>
> >>> Andras
> >>>
> >>> -----Original Message-----
> >>> From: David Lonie [mailto:david.lonie at kitware.com]
> >>> Sent: Friday, June 23, 2017 1:51 PM
> >>> To: Shawn Waldon <shawn.waldon at kitware.com>
> >>> Cc: Andras Lasso <lasso at queensu.ca>; VTK Developers
> >>> <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
> >>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
> >>>
> >>> I'm so glad someone brought this up =)
> >>>
> >>> On Fri, Jun 23, 2017 at 10:52 AM, Shawn Waldon <
> shawn.waldon at kitware.com> wrote:
> >>>>  But realistically what it does is
> >>>> discourage use of vtkNew.  Most people I talk to say "I would use
> >>>> vtkNew but then I have to clutter up my code with GetPointer calls
> >>>> everywhere" and so they still use vtkSmartPointer.  Honestly I only
> >>>> used it to clean up declarations (the problem discussed earlier in
> >>>> this thread).  Now that we can use auto in VTK, I'll probably go back
> >>>> to vtkSmartPointer since it is easier to use.
> >>>
> >>> I agree with Shawn. It's an unnecessary hassle to require the Get() to
> be used.
> >>>
> >>> I suppose I'm just a fan of the design philosophy for C++ about "don't
> prevent developers from shooting themselves in the foot." If a dev doesn't
> understand VTK's reference counting well enough to understand that you
> can't simply return a vtkNew'd pointer without increfing it first, they're
> going to have far greater problems using the toolkit than this.
> >>>
> >>> Besides, you could easily (and safely) return a vtkNew'd pointer from
> a function:
> >>>
> >>> vtkObject* function()
> >>> {
> >>>   vtkNew<vtkObject> obj;
> >>>   obj->Register();
> >>>   return obj; // If we had implicit conversions, anyway }
> >>>
> >>> Making the class unwieldly simply so that people don't need to learn
> how reference counts work is a poor justification IMO.
> >>>
> >>> Just my 2c,
> >>> Dave
> >>> _______________________________________________
> >>> Powered by
> >>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&dat
> >>> a=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd6
> >>> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=EWly
> >>> 8qDaOVuCYOrDhoQ7SyY3glwTdlm1J1nxY%2BBDO50%3D&reserved=0
> >>>
> >>> Visit other Kitware open-source projects at
> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki
> >>> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queens
> >>> u.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b
> >>> 925c%7C1%7C0%7C636339189405346369&sdata=v7U9kMfdmgpWZ6WYn1nyPTuUHWzn4s
> >>> J6XvYEJdpw50I%3D&reserved=0
> >>>
> >>> Search the list archives at:
> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkma
> >>> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu
> >>> .ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b9
> >>> 25c%7C1%7C0%7C636339189405346369&sdata=otfBLrSAA5d7a9u6mrb56%2ByrIVM%2
> >>> Bl3f%2BZNQpwOvqgO0%3D&reserved=0
> >>>
> >>> Follow this link to subscribe/unsubscribe:
> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic
> >>> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&
> data=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%
> 7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=
> whCFetn1LnPSRi0CZ%2BD1aGlMHqdv5vSgzkRdcuLw8qI%3D&reserved=0
> >>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170625/97ee606f/attachment.html>

From elvis.stansvik at orexplore.com  Sun Jun 25 05:50:17 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Sun, 25 Jun 2017 11:50:17 +0200
Subject: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
In-Reply-To: <CAHDsG9NfD5Cznin09LUKXwrMVFFeUFsU7XeMMYo8RKU6VS5nLw@mail.gmail.com>
References: <mailman.5608.1498157838.15420.vtk-developers@vtk.org>
 <CAHDsG9OkQ-kLMTdTwkJnOY+uWfAEVMU5=BEa=VU7ZTjVoheggA@mail.gmail.com>
 <CAE-7VJk--nWUvfwXAkBZACPRbb870uQR1sMFiNKzh_=SLNJQuw@mail.gmail.com>
 <CAE-7VJ=fY3E5D_UfPsQACp2k94fXZzt3WcjQkwGZPjYfA3yWTA@mail.gmail.com>
 <CAE-7VJmbcs6XmHa02BRVQD_FCNAKQY=DOYLR9eq7w2muFnAQEg@mail.gmail.com>
 <CAKME8fFiQF9OTTyrwqf8o3ktKXJ12naQQ2400NPQxoTuquBkeQ@mail.gmail.com>
 <BY2PR0701MB194148A23E9064A93DA88E43D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAKME8fHEnqBJ7036xX6e06Qa3-KbsFQPd81=Q6K8EAmn1P6wvQ@mail.gmail.com>
 <BY2PR0701MB1941606C2D0063812CE556A1D8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <7B3231C9-9BC9-490A-927E-4CDD0DE9F9F4@aol.com>
 <BY2PR0701MB1941A74AD737A0D89DD48D9CD8D80@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CALSpCT1BxGb3k7H4FRhYSt-7tBdfL=uTDWkH50zD+jmXWu0OEA@mail.gmail.com>
 <CA+=e1ouZcoUppjJPSEgLT427egKV8F5y9EFxmeWYZi9Woq0wqw@mail.gmail.com>
 <BY2PR0701MB19419DA8516C259A195589BCD8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJnq28r+dDNn=f4GCHCGixHt3EDH5tCLps97c2N_oqyV3g@mail.gmail.com>
 <BY2PR0701MB19417901903752ABEB42D414D8D90@BY2PR0701MB1941.namprd07.prod.outlook.com>
 <CAE-7VJ=65URUp2eZi2USNvaUu0HfeVgk7g6VLFu29LuOeMoZJg@mail.gmail.com>
 <CAE-7VJ=mvm2zOrOOe6f7YU7Rr-UmjASgFeFzF_K7M2gcQDokvg@mail.gmail.com>
 <CAHDsG9NfD5Cznin09LUKXwrMVFFeUFsU7XeMMYo8RKU6VS5nLw@mail.gmail.com>
Message-ID: <CAE-7VJnaE80OiLhRCYQLc6U_CSFPuLAbvhKLD9+qen7vkAyS+g@mail.gmail.com>

2017-06-25 11:13 GMT+02:00 Andrew Maclean <andrew.amaclean at gmail.com>:
> This table may be useful to see what features are supported:
> http://en.cppreference.com/w/cpp/compiler_support
>
> Please also remember that we need to ensure that the VTK7.x series are also
> supported, not just VTK8+.

Right, nothing in the code would be changed except initializations on
the form vtkSmartPointer<Type> var = vtkSmartPointer<Type>.

Looks like auto has been supported in all major compilers since 2010.

Elvis

>
> Personally I have no problems with new submissions using C++11 features.
>
> Andrew Maclean
>
> On 25 Jun 2017 18:43, "Elvis Stansvik" <elvis.stansvik at orexplore.com> wrote:
>>
>> But, going back to my original proposal now.
>>
>> 1. Using auto -> not a good idea since people may want to compile with
>> older compilers
>> 2. Using vtkNew -> not a good idea since all the .Get() / .GetPointer()
>> are ugly
>> 3. Tidying up variable names (e.g. "iren", "renWin", ...) -> I got
>> some opposition to that too
>>
>> So I guess I'll hold off on doing anything for now.
>>
>> Though re. 1, what compilers don't support C++11 nowadays? I
>> personally think that would be sufficiently rare at this point that
>> those users could adapt the examples to fit their old compiler.
>>
>> But I guess the bigger question is whether the examples should be
>> curated at all, or always left intact, to not discourage contribution?
>>
>> Elvis
>>
>> 2017-06-25 10:27 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>> > 2017-06-24 22:07 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
>> >> It is great that you've brought this up! There is a very important,
>> >> fundamental difference. Unlike std::shared_ptr or QSharedPointer, VTK smart
>> >> pointer does NOT need clear distinction between the pointer object and the
>> >> raw pointer it holds, because reference counting is implemented in the
>> >> managed object itself.
>> >>
>> >> See in std::shared_ptr documentation: "Constructing a new shared_ptr
>> >> using the raw underlying pointer owned by another shared_ptr leads to
>> >> undefined behavior." (http://en.cppreference.com/w/cpp/memory/shared_ptr)
>> >>
>> >> In VTK, if you assign a vtkSmartPointer to another, internally the raw
>> >> pointer is retrieved and used (Common/Core/vtkSmartPointer.h):
>> >>
>> >>   vtkSmartPointer& operator=(const vtkSmartPointer<U>& r)
>> >>   {
>> >>     this->vtkSmartPointerBase::operator=(CheckType(r.GetPointer()));
>> >>     return *this;
>> >>   }
>> >>
>> >> VTK smart pointers work differently from STL and Qt, so it is
>> >> reasonable to use a different API that reflects this difference. As VTK
>> >> allows safe use of a simpler API, we should take advantage of that and use
>> >> it.
>> >
>> > That's a good point, and an important difference.
>> >
>> > Though, it's still unsafe (of course) in VTK to do say (pseudo):
>> >
>> > struct MyClass {
>> >     void setArray(vtkDataArray *arr) { a = arr; }
>> >     void doSomething() { /* Use the a member here */ }
>> >
>> >     vtkDataArray *a;
>> > }
>> >
>> > and then
>> >
>> > MyClass c;
>> >
>> > { // some scope somewhere
>> >     vtkNew<vtkDataArray> a;
>> >     ...
>> >     c.func(a);
>> > } // a dies (internal pointer freed), c survives
>> >
>> > c.doSomething(); // oops
>> >
>> > But I guess this should be filed in the 'so stupid the user should not
>> > be "protected" from it by a slightly awkward .Get()' category.
>> >
>> > I think you have my vote to add implicit conversion as well.
>> >
>> > Elvis
>> >
>> >>
>> >> Andras
>> >>
>> >> -----Original Message-----
>> >> From: Elvis Stansvik [mailto:elvis.stansvik at orexplore.com]
>> >> Sent: Saturday, June 24, 2017 12:36 PM
>> >> To: Andras Lasso <lasso at queensu.ca>
>> >> Cc: David Lonie <david.lonie at kitware.com>; Shawn Waldon
>> >> <shawn.waldon at kitware.com>; VTK Developers <vtk-developers at vtk.org>; Andrew
>> >> Maclean <andrew.amaclean at gmail.com>
>> >> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>> >>
>> >> 2017-06-24 15:53 GMT+02:00 Andras Lasso <lasso at queensu.ca>:
>> >>> Based on the feedbacks and the poll results (11 out of 13 votes for
>> >>> changing current behavior), it seems there is a strong consensus for
>> >>> adding implicit conversion.
>> >>
>> >> I was away and missed the vote, but frankly I'm not sure what I would
>> >> have voted.
>> >>
>> >> Looking at what others do, I guess vtkNew is comparable to
>> >> std::unique_ptr or Qt's QScopedPointer, none of which do implicit conversion
>> >> to the underlying pointer (they have .get() and .data() respectively). So
>> >> VTK would be rather unique in doing that for a scoped smart pointer I
>> >> think..
>> >>
>> >> Elvis
>> >>
>> >>>
>> >>> Here is a pull request with the change:
>> >>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
>> >>> b.kitware.com%2Fvtk%2Fvtk%2Fmerge_requests%2F2961&data=02%7C01%7Classo
>> >>> %40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c
>> >>> 4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=2Jv0QS1qlRUgSJvN%2BO8
>> >>> 0pXOt89kKC0NP7iXXRr2mg30%3D&reserved=0
>> >>>
>> >>> Andras
>> >>>
>> >>> -----Original Message-----
>> >>> From: David Lonie [mailto:david.lonie at kitware.com]
>> >>> Sent: Friday, June 23, 2017 1:51 PM
>> >>> To: Shawn Waldon <shawn.waldon at kitware.com>
>> >>> Cc: Andras Lasso <lasso at queensu.ca>; VTK Developers
>> >>> <vtk-developers at vtk.org>; Andrew Maclean <andrew.amaclean at gmail.com>
>> >>> Subject: Re: [vtk-developers] vtk-developers Digest, Vol 158, Issue 21
>> >>>
>> >>> I'm so glad someone brought this up =)
>> >>>
>> >>> On Fri, Jun 23, 2017 at 10:52 AM, Shawn Waldon
>> >>> <shawn.waldon at kitware.com> wrote:
>> >>>>  But realistically what it does is
>> >>>> discourage use of vtkNew.  Most people I talk to say "I would use
>> >>>> vtkNew but then I have to clutter up my code with GetPointer calls
>> >>>> everywhere" and so they still use vtkSmartPointer.  Honestly I only
>> >>>> used it to clean up declarations (the problem discussed earlier in
>> >>>> this thread).  Now that we can use auto in VTK, I'll probably go back
>> >>>> to vtkSmartPointer since it is easier to use.
>> >>>
>> >>> I agree with Shawn. It's an unnecessary hassle to require the Get() to
>> >>> be used.
>> >>>
>> >>> I suppose I'm just a fan of the design philosophy for C++ about "don't
>> >>> prevent developers from shooting themselves in the foot." If a dev doesn't
>> >>> understand VTK's reference counting well enough to understand that you can't
>> >>> simply return a vtkNew'd pointer without increfing it first, they're going
>> >>> to have far greater problems using the toolkit than this.
>> >>>
>> >>> Besides, you could easily (and safely) return a vtkNew'd pointer from
>> >>> a function:
>> >>>
>> >>> vtkObject* function()
>> >>> {
>> >>>   vtkNew<vtkObject> obj;
>> >>>   obj->Register();
>> >>>   return obj; // If we had implicit conversions, anyway }
>> >>>
>> >>> Making the class unwieldly simply so that people don't need to learn
>> >>> how reference counts work is a poor justification IMO.
>> >>>
>> >>> Just my 2c,
>> >>> Dave
>> >>> _______________________________________________
>> >>> Powered by
>> >>> https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&dat
>> >>> a=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd6
>> >>> 1ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=EWly
>> >>> 8qDaOVuCYOrDhoQ7SyY3glwTdlm1J1nxY%2BBDO50%3D&reserved=0
>> >>>
>> >>> Visit other Kitware open-source projects at
>> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ki
>> >>> tware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queens
>> >>> u.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b
>> >>> 925c%7C1%7C0%7C636339189405346369&sdata=v7U9kMfdmgpWZ6WYn1nyPTuUHWzn4s
>> >>> J6XvYEJdpw50I%3D&reserved=0
>> >>>
>> >>> Search the list archives at:
>> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkma
>> >>> il.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu
>> >>> .ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b9
>> >>> 25c%7C1%7C0%7C636339189405346369&sdata=otfBLrSAA5d7a9u6mrb56%2ByrIVM%2
>> >>> Bl3f%2BZNQpwOvqgO0%3D&reserved=0
>> >>>
>> >>> Follow this link to subscribe/unsubscribe:
>> >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic
>> >>>
>> >>> .kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C14c5314b70e443f5be4908d4bb1f0bf4%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636339189405346369&sdata=whCFetn1LnPSRi0CZ%2BD1aGlMHqdv5vSgzkRdcuLw8qI%3D&reserved=0
>> >>>

From bill.lorensen at gmail.com  Sun Jun 25 14:56:59 2017
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Sun, 25 Jun 2017 14:56:59 -0400
Subject: [vtk-developers] VTKExamples now supports lazy loading of images
Message-ID: <CADZJ4hM6yW2Kto7ywbSWTkjtFcy-G0hKao14sT80AcShHO5ifA@mail.gmail.com>

Folks,

Github has a rate limit for loading images. So a page like
https://lorensen.github.io/VTKExamples/site/Cxx/

with over 250 thumbnails quickly hits the rate limit and the images do
not display. Further, if you click on an example, the image for that
example will not display. After a short time, a refresh will show the
image.

I have added lazy loading of images. Images are only loaded when they
appear in the viewport, This helps alleviate  the rate limit issue.
Still, if you page through the entire Cxx page, you will reach that
limit.

This will also make the page loading of large pages to go faster.

Bill

-- 
Unpaid intern in BillsBasement at noware dot com

From marcus.hanwell at kitware.com  Mon Jun 26 13:06:08 2017
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Mon, 26 Jun 2017 13:06:08 -0400
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
Message-ID: <CAMkPkZWCY+Wats4gY8jko=Py=Y2=9S3EO+6fK7_0tz1259iE3w@mail.gmail.com>

On Thu, Jun 22, 2017 at 1:01 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
> I prefer vtkSmartPointer because it can be used like any other vtk
> pointer. No need for a GetPointer() is some cases. The example writer
> is free to use vtkSmartPointer or vtkNew. But I would leave them as
> there are.
>
If that is detracting from using vtkNew then I think we should add the
single line to vtkNew. This has bothered me for a while, and I think
it is fair to make vtkNew behave more like the other two pointer
classes. I liked the explicitness of calling Get(), but think it makes
what would otherwise be more convenient a little harder to use.

I will see about putting in a patch for this soon. I really would
rather get rid of the duplication in the examples by preferring vtkNew
or using auto. It is harder to read, and needlessly repeats the class
name in my opinion.

From brad.king at kitware.com  Mon Jun 26 14:07:49 2017
From: brad.king at kitware.com (Brad King)
Date: Mon, 26 Jun 2017 14:07:49 -0400
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CAMkPkZWCY+Wats4gY8jko=Py=Y2=9S3EO+6fK7_0tz1259iE3w@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
 <CAMkPkZWCY+Wats4gY8jko=Py=Y2=9S3EO+6fK7_0tz1259iE3w@mail.gmail.com>
Message-ID: <be52124e-4224-5188-f2ee-306e906effd0@kitware.com>

On 06/26/2017 01:06 PM, Marcus D. Hanwell wrote:
> If that is detracting from using vtkNew then I think we should add the
> single line to vtkNew.
> 
> I will see about putting in a patch for this soon. I really would
> rather get rid of the duplication in the examples by preferring vtkNew
> or using auto. It is harder to read, and needlessly repeats the class
> name in my opinion.

FYI: https://gitlab.kitware.com/vtk/vtk/merge_requests/2961

-Brad


From marcus.hanwell at kitware.com  Mon Jun 26 15:07:39 2017
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Mon, 26 Jun 2017 15:07:39 -0400
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <be52124e-4224-5188-f2ee-306e906effd0@kitware.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
 <CAMkPkZWCY+Wats4gY8jko=Py=Y2=9S3EO+6fK7_0tz1259iE3w@mail.gmail.com>
 <be52124e-4224-5188-f2ee-306e906effd0@kitware.com>
Message-ID: <CAMkPkZW+FEatJEXcz24whurYKzPbSXXUN7nWqGYxs_-eX-_XMw@mail.gmail.com>

On Mon, Jun 26, 2017 at 2:07 PM, Brad King <brad.king at kitware.com> wrote:
> On 06/26/2017 01:06 PM, Marcus D. Hanwell wrote:
>> If that is detracting from using vtkNew then I think we should add the
>> single line to vtkNew.
>>
>> I will see about putting in a patch for this soon. I really would
>> rather get rid of the duplication in the examples by preferring vtkNew
>> or using auto. It is harder to read, and needlessly repeats the class
>> name in my opinion.
>
> FYI: https://gitlab.kitware.com/vtk/vtk/merge_requests/2961
>
Thanks Brad, Bill pointed it out to me and I commented. I think it is
time to make the vtkNew interface more consistent, and I regret my
youthful desire for purity in the face of inconsistency :-)

From DLRdave at aol.com  Mon Jun 26 15:30:00 2017
From: DLRdave at aol.com (David Cole)
Date: Mon, 26 Jun 2017 15:30:00 -0400
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CAMkPkZW+FEatJEXcz24whurYKzPbSXXUN7nWqGYxs_-eX-_XMw@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
 <CAMkPkZWCY+Wats4gY8jko=Py=Y2=9S3EO+6fK7_0tz1259iE3w@mail.gmail.com>
 <be52124e-4224-5188-f2ee-306e906effd0@kitware.com>
 <CAMkPkZW+FEatJEXcz24whurYKzPbSXXUN7nWqGYxs_-eX-_XMw@mail.gmail.com>
Message-ID: <CAKME8fHTbE_pVJ8d4JMbX13-n=4tCkGojs3Ri9u-14Xd9JHVuA@mail.gmail.com>

I hereby retract my "disastrous" comment from the other email thread
on this topic...

On Mon, Jun 26, 2017 at 3:07 PM, Marcus D. Hanwell
<marcus.hanwell at kitware.com> wrote:
> On Mon, Jun 26, 2017 at 2:07 PM, Brad King <brad.king at kitware.com> wrote:
>> On 06/26/2017 01:06 PM, Marcus D. Hanwell wrote:
>>> If that is detracting from using vtkNew then I think we should add the
>>> single line to vtkNew.
>>>
>>> I will see about putting in a patch for this soon. I really would
>>> rather get rid of the duplication in the examples by preferring vtkNew
>>> or using auto. It is harder to read, and needlessly repeats the class
>>> name in my opinion.
>>
>> FYI: https://gitlab.kitware.com/vtk/vtk/merge_requests/2961
>>
> Thanks Brad, Bill pointed it out to me and I commented. I think it is
> time to make the vtkNew interface more consistent, and I regret my
> youthful desire for purity in the face of inconsistency :-)
> _______________________________________________
> 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
>

From marcus.hanwell at kitware.com  Mon Jun 26 15:47:27 2017
From: marcus.hanwell at kitware.com (Marcus D. Hanwell)
Date: Mon, 26 Jun 2017 15:47:27 -0400
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CAKME8fHTbE_pVJ8d4JMbX13-n=4tCkGojs3Ri9u-14Xd9JHVuA@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
 <CAMkPkZWCY+Wats4gY8jko=Py=Y2=9S3EO+6fK7_0tz1259iE3w@mail.gmail.com>
 <be52124e-4224-5188-f2ee-306e906effd0@kitware.com>
 <CAMkPkZW+FEatJEXcz24whurYKzPbSXXUN7nWqGYxs_-eX-_XMw@mail.gmail.com>
 <CAKME8fHTbE_pVJ8d4JMbX13-n=4tCkGojs3Ri9u-14Xd9JHVuA@mail.gmail.com>
Message-ID: <CAMkPkZVvGG_Wbd8Jo1D5payY3UH6z_uKTtA2_gCfcMTuruaiog@mail.gmail.com>

On Mon, Jun 26, 2017 at 3:30 PM, David Cole <DLRdave at aol.com> wrote:
> I hereby retract my "disastrous" comment from the other email thread
> on this topic...
>
That was quite a thread, it was hidden by a terrible subject that gave
me no idea what it was about. I think I was with you, but as vtkObject
derived classes are all reference counted, and vtkSmartPointer/vtkNew
are effectively the same as far as risk of going out of
scope/returning a dangling pointer we should be consistent.

I am not a fan of either implicitly converting, but if one does it
they both should. I was just being cautious at the time, but I think
it was the wrong call, and would prefer consistency. I routinely use
vtkSmartPointer and vtkNew in class design to take care of objects,
and when switching between the two it is a pain because of the
inconsistency.

I had been planning to propose this patch for a while, and am glad
someone else did. It is a simple change, but it makes using the two
far more interchangeable, and will hopefully encourage more people to
use our pointer classes to aid with memory management, and banish the
smart pointer creation macros littering tests.

From lasso at queensu.ca  Mon Jun 26 19:34:41 2017
From: lasso at queensu.ca (Andras Lasso)
Date: Mon, 26 Jun 2017 23:34:41 +0000
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <CAMkPkZVvGG_Wbd8Jo1D5payY3UH6z_uKTtA2_gCfcMTuruaiog@mail.gmail.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
 <CAMkPkZWCY+Wats4gY8jko=Py=Y2=9S3EO+6fK7_0tz1259iE3w@mail.gmail.com>
 <be52124e-4224-5188-f2ee-306e906effd0@kitware.com>
 <CAMkPkZW+FEatJEXcz24whurYKzPbSXXUN7nWqGYxs_-eX-_XMw@mail.gmail.com>
 <CAKME8fHTbE_pVJ8d4JMbX13-n=4tCkGojs3Ri9u-14Xd9JHVuA@mail.gmail.com>
 <CAMkPkZVvGG_Wbd8Jo1D5payY3UH6z_uKTtA2_gCfcMTuruaiog@mail.gmail.com>
Message-ID: <BY2PR0701MB1941D8F8B73130C60729285BD8DF0@BY2PR0701MB1941.namprd07.prod.outlook.com>

Thanks for all the comments on this topic. I've updated the pull request (squashed commits, included main points from the discussions):

https://gitlab.kitware.com/lassoan/vtk/commit/00bf5f3d3acf655e396feb4d3b7167806aba05b9

Andras

-----Original Message-----
From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Marcus D. Hanwell
Sent: Monday, June 26, 2017 9:47 PM
To: David Cole <DLRdave at aol.com>
Cc: VTK Developers <vtk-developers at vtk.org>; Brad King <brad.king at kitware.com>
Subject: Re: [vtk-developers] vtkNew in examples (or auto?)

On Mon, Jun 26, 2017 at 3:30 PM, David Cole <DLRdave at aol.com> wrote:
> I hereby retract my "disastrous" comment from the other email thread 
> on this topic...
>
That was quite a thread, it was hidden by a terrible subject that gave me no idea what it was about. I think I was with you, but as vtkObject derived classes are all reference counted, and vtkSmartPointer/vtkNew are effectively the same as far as risk of going out of scope/returning a dangling pointer we should be consistent.

I am not a fan of either implicitly converting, but if one does it they both should. I was just being cautious at the time, but I think it was the wrong call, and would prefer consistency. I routinely use vtkSmartPointer and vtkNew in class design to take care of objects, and when switching between the two it is a pain because of the inconsistency.

I had been planning to propose this patch for a while, and am glad someone else did. It is a simple change, but it makes using the two far more interchangeable, and will hopefully encourage more people to use our pointer classes to aid with memory management, and banish the smart pointer creation macros littering tests.
_______________________________________________
Powered by https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C02ba850c4d54497c377408d4bccc2f2f%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636341032526560231&sdata=8qrELn4ovJgQN7AjOI8E3FDzrU%2FudajhRDLyeUpCoYg%3D&reserved=0

Visit other Kitware open-source projects at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C02ba850c4d54497c377408d4bccc2f2f%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636341032526560231&sdata=j%2BaQLKquqzpFouD%2BxG0Mu%2FK7vDiyhWkVy2AcH2y8whE%3D&reserved=0

Search the list archives at: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C02ba850c4d54497c377408d4bccc2f2f%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636341032526560231&sdata=6XZzGlIeDboJvRDMokX422KvtmCrIltQtXD4vRE20bY%3D&reserved=0

Follow this link to subscribe/unsubscribe:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C02ba850c4d54497c377408d4bccc2f2f%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636341032526560231&sdata=3Mffbxh0OuhI%2FEd83nrkhyOelfKcmG1pq99WstkE1Vw%3D&reserved=0


From elvis.stansvik at orexplore.com  Tue Jun 27 02:42:30 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Tue, 27 Jun 2017 08:42:30 +0200
Subject: [vtk-developers] vtkNew in examples (or auto?)
In-Reply-To: <BY2PR0701MB1941D8F8B73130C60729285BD8DF0@BY2PR0701MB1941.namprd07.prod.outlook.com>
References: <CAE-7VJn169=XjsYnxmwexvoEVfK5iYmfiqNEbsuy6BbqJTikSA@mail.gmail.com>
 <CADZJ4hOWiMia2haOvSe_aaUaUVNYZHCjxVd4564g+St7ii4shA@mail.gmail.com>
 <CAMkPkZWCY+Wats4gY8jko=Py=Y2=9S3EO+6fK7_0tz1259iE3w@mail.gmail.com>
 <be52124e-4224-5188-f2ee-306e906effd0@kitware.com>
 <CAMkPkZW+FEatJEXcz24whurYKzPbSXXUN7nWqGYxs_-eX-_XMw@mail.gmail.com>
 <CAKME8fHTbE_pVJ8d4JMbX13-n=4tCkGojs3Ri9u-14Xd9JHVuA@mail.gmail.com>
 <CAMkPkZVvGG_Wbd8Jo1D5payY3UH6z_uKTtA2_gCfcMTuruaiog@mail.gmail.com>
 <BY2PR0701MB1941D8F8B73130C60729285BD8DF0@BY2PR0701MB1941.namprd07.prod.outlook.com>
Message-ID: <CAE-7VJmMQpSydoBu_kc0HV0Qny-9MUg2L-fioO2sWZBMXfA5LQ@mail.gmail.com>

Den 27 juni 2017 1:34 fm skrev "Andras Lasso" <lasso at queensu.ca>:
>
> Thanks for all the comments on this topic. I've updated the pull request
(squashed commits, included main points from the discussions):

Thanks a lot for taking care of this.

Now, my original post was about the examples. Those will naturally not be
updated to take care of this brand new functionality, since they need to
work with older VTKs.

However, regarding the auto keyword for declarations (but keeping the use
of vtkSmartPointer intact): The objection to that was older compilers, but
auto has been supported in all major compilers since 2010.

I'd like to get some more opinions on this. Personally I think compilers
lacking auto is so rare that the improved readability of the examples
outweigh the inconvenience of those who use old compilers (who will have to
adapt the examples).

Should we have a poll on this, like was done for vtkNew implicit conversion?

Elvis

>
>
https://gitlab.kitware.com/lassoan/vtk/commit/00bf5f3d3acf655e396feb4d3b7167806aba05b9
>
> Andras
>
> -----Original Message-----
> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of
Marcus D. Hanwell
> Sent: Monday, June 26, 2017 9:47 PM
> To: David Cole <DLRdave at aol.com>
> Cc: VTK Developers <vtk-developers at vtk.org>; Brad King <
brad.king at kitware.com>
> Subject: Re: [vtk-developers] vtkNew in examples (or auto?)
>
> On Mon, Jun 26, 2017 at 3:30 PM, David Cole <DLRdave at aol.com> wrote:
> > I hereby retract my "disastrous" comment from the other email thread
> > on this topic...
> >
> That was quite a thread, it was hidden by a terrible subject that gave me
no idea what it was about. I think I was with you, but as vtkObject derived
classes are all reference counted, and vtkSmartPointer/vtkNew are
effectively the same as far as risk of going out of scope/returning a
dangling pointer we should be consistent.
>
> I am not a fan of either implicitly converting, but if one does it they
both should. I was just being cautious at the time, but I think it was the
wrong call, and would prefer consistency. I routinely use vtkSmartPointer
and vtkNew in class design to take care of objects, and when switching
between the two it is a pain because of the inconsistency.
>
> I had been planning to propose this patch for a while, and am glad
someone else did. It is a simple change, but it makes using the two far
more interchangeable, and will hopefully encourage more people to use our
pointer classes to aid with memory management, and banish the smart pointer
creation macros littering tests.
> _______________________________________________
> Powered by
https://na01.safelinks.protection.outlook.com/?url=www.kitware.com&data=02%7C01%7Classo%40queensu.ca%7C02ba850c4d54497c377408d4bccc2f2f%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636341032526560231&sdata=8qrELn4ovJgQN7AjOI8E3FDzrU%2FudajhRDLyeUpCoYg%3D&reserved=0
>
> Visit other Kitware open-source projects at
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.kitware.com%2Fopensource%2Fopensource.html&data=02%7C01%7Classo%40queensu.ca%7C02ba850c4d54497c377408d4bccc2f2f%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636341032526560231&sdata=j%2BaQLKquqzpFouD%2BxG0Mu%2FK7vDiyhWkVy2AcH2y8whE%3D&reserved=0
>
> Search the list archives at:
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmarkmail.org%2Fsearch%2F%3Fq%3Dvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C02ba850c4d54497c377408d4bccc2f2f%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636341032526560231&sdata=6XZzGlIeDboJvRDMokX422KvtmCrIltQtXD4vRE20bY%3D&reserved=0
>
> Follow this link to subscribe/unsubscribe:
>
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpublic.kitware.com%2Fmailman%2Flistinfo%2Fvtk-developers&data=02%7C01%7Classo%40queensu.ca%7C02ba850c4d54497c377408d4bccc2f2f%7Cd61ecb3b38b142d582c4efb2838b925c%7C1%7C0%7C636341032526560231&sdata=3Mffbxh0OuhI%2FEd83nrkhyOelfKcmG1pq99WstkE1Vw%3D&reserved=0
>
> _______________________________________________
> 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/20170627/5cd9c830/attachment-0001.html>

From prakeshofficial at gmail.com  Tue Jun 27 03:27:53 2017
From: prakeshofficial at gmail.com (rakesh patil)
Date: Tue, 27 Jun 2017 12:57:53 +0530
Subject: [vtk-developers] Exporting to vector format problem.
Message-ID: <CAOG35ckc60-KF0vUGz8jH_-hwwB2H6XJ6iBOP9mDrrN0+R1QHg@mail.gmail.com>

Hi,

I have derived my own class from vtkScalarBarActor. I have redefined
ConfigureScalarBar() function. I am getting the desired output on the
render window. When I export the renderwindow contents to vector format
using vtkGL2PSExporter, the output PS file misses drawing the colour bar.
If I replace my derived class with vtkScalarBarActor, the PS file shows
proper output. Really wondering what might have gone wrong.

Attached the code of my derived class. Experienced users/VTK developers,
help me out to fix this problem.

Thanks & Regards
Rakesh Patil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170627/b764c1f8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MyScalarBarActor.zip
Type: application/zip
Size: 6191 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170627/b764c1f8/attachment.zip>

From ansha.kamath at gmail.com  Tue Jun 27 05:27:19 2017
From: ansha.kamath at gmail.com (anusha_kamath)
Date: Tue, 27 Jun 2017 02:27:19 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <1498186501910-5743740.post@n5.nabble.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
 <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
 <1498159865720-5743734.post@n5.nabble.com>
 <CAL=Mvsp=Mo2gfULdrdgoucpzytTgRgGXefOp7ik=c2QkXMfJrQ@mail.gmail.com>
 <1498171472336-5743737.post@n5.nabble.com>
 <1498186501910-5743740.post@n5.nabble.com>
Message-ID: <1498555639546-5743791.post@n5.nabble.com>

Hi!
I compiled with cmake using the same options mentioned ,but cmake error
"error in generation process project files may be invalid" pops on the
screen.Could u please help me with this? 



--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731p5743791.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From sankhesh.jhaveri at kitware.com  Tue Jun 27 10:57:59 2017
From: sankhesh.jhaveri at kitware.com (Sankhesh Jhaveri)
Date: Tue, 27 Jun 2017 14:57:59 +0000
Subject: [vtk-developers] Announce: vtk 8.0.0 is ready!
Message-ID: <CAEcL5t4d2Xghno=m3MP=Vk0Oc4pwwXwW6ddP-rD00-HsgV-ZPw@mail.gmail.com>

The VTK maintenance team is happy to announce the eighth major release of
VTK. Special thanks go out to everyone who tested and provided feedback and
fixes during the release candidate cycle.

You can find the source, data and documentation tarballs on the VTK website
<http://www.vtk.org/download/#release>. Please find detailed release notes
here: https://blog.kitware.com/vtk-8-0-0/.

As always, contact Kitware <https://www.kitware.com> and the mailing lists
for assistance.

Thank,
VTK Maintenance Team
?
-- 
Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware
<http://www.kitware.com/> | (518) 881-4417
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170627/6c46e189/attachment.html>

From david.lonie at kitware.com  Tue Jun 27 11:00:10 2017
From: david.lonie at kitware.com (David Lonie)
Date: Tue, 27 Jun 2017 11:00:10 -0400
Subject: [vtk-developers] Exporting to vector format problem.
In-Reply-To: <CAOG35ckc60-KF0vUGz8jH_-hwwB2H6XJ6iBOP9mDrrN0+R1QHg@mail.gmail.com>
References: <CAOG35ckc60-KF0vUGz8jH_-hwwB2H6XJ6iBOP9mDrrN0+R1QHg@mail.gmail.com>
Message-ID: <CA+=e1otPvPD3g31rATKbTrXFkf5CAdXcBKPW7WHUw7Ye+14o0w@mail.gmail.com>

On the OpenGL backend, the scalar bar is handled specially by the
GL2PS export code. See
https://gitlab.kitware.com/vtk/vtk/blob/master/IO/ExportOpenGL/vtkOpenGLGL2PSExporter.cxx#L798

Exporting vector graphics through GL2PS is a rather tedious process
that requires some manual setup for certain actors. In this case, we
need to specially handle the scalar bar in order to get the textured
color bar to appear correctly. I don't see a way to work around this
without modifying the exporter itself.

On the OpenGL2 backend, the whole thing will be exported as a raster
image, aside from the text labels which will be scalable. So you
should at least see something in the output from the new backend.

HTH,
Dave

On Tue, Jun 27, 2017 at 3:27 AM, rakesh patil <prakeshofficial at gmail.com> wrote:
> Hi,
>
> I have derived my own class from vtkScalarBarActor. I have redefined
> ConfigureScalarBar() function. I am getting the desired output on the render
> window. When I export the renderwindow contents to vector format using
> vtkGL2PSExporter, the output PS file misses drawing the colour bar. If I
> replace my derived class with vtkScalarBarActor, the PS file shows proper
> output. Really wondering what might have gone wrong.
>
> Attached the code of my derived class. Experienced users/VTK developers,
> help me out to fix this problem.
>
> Thanks & Regards
> Rakesh Patil
>
> _______________________________________________
> 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
>
>

From elvis.stansvik at orexplore.com  Tue Jun 27 12:14:10 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Tue, 27 Jun 2017 18:14:10 +0200
Subject: [vtk-developers] [vtkusers] Announce: vtk 8.0.0 is ready!
In-Reply-To: <CAEcL5t4d2Xghno=m3MP=Vk0Oc4pwwXwW6ddP-rD00-HsgV-ZPw@mail.gmail.com>
References: <CAEcL5t4d2Xghno=m3MP=Vk0Oc4pwwXwW6ddP-rD00-HsgV-ZPw@mail.gmail.com>
Message-ID: <CAE-7VJnixtfzXPWOfDgg_6KxAMntLcPznjMHxV+STRDA19v35Q@mail.gmail.com>

Den 27 juni 2017 4:58 em skrev "Sankhesh Jhaveri" <
sankhesh.jhaveri at kitware.com>:
>
> The VTK maintenance team is happy to announce the eighth major release of
VTK. Special thanks go out to everyone who tested and provided feedback and
fixes during the release candidate cycle.

Excellent, many thanks!

It would be great if someone with the necessary bits could assign the
Windows/Intel volume rendering bug I reported to a milestone:

https://gitlab.kitware.com/vtk/vtk/issues/17058

I can't seem to do it myself, but on vtk-developers I was told this would
probably be worked on for the next point release.

It means volume rendering in PV is currently broken on Windows +
Haswell/Ivy Bridge, so I hope it's up there on the priority list.

Elvis

>
> You can find the source, data and documentation tarballs on the VTK
website. Please find detailed release notes here:
https://blog.kitware.com/vtk-8-0-0/.
>
> As always, contact Kitware and the mailing lists for assistance.
>
> Thank,
> VTK Maintenance Team
>
> ?
> --
> Sankhesh Jhaveri
> Sr. Research & Development Engineer | Kitware | (518) 881-4417
> ?
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170627/dfb62116/attachment.html>

From dave.demarle at kitware.com  Tue Jun 27 12:19:20 2017
From: dave.demarle at kitware.com (David E DeMarle)
Date: Tue, 27 Jun 2017 12:19:20 -0400
Subject: [vtk-developers] [vtkusers] Announce: vtk 8.0.0 is ready!
In-Reply-To: <CAE-7VJnixtfzXPWOfDgg_6KxAMntLcPznjMHxV+STRDA19v35Q@mail.gmail.com>
References: <CAEcL5t4d2Xghno=m3MP=Vk0Oc4pwwXwW6ddP-rD00-HsgV-ZPw@mail.gmail.com>
 <CAE-7VJnixtfzXPWOfDgg_6KxAMntLcPznjMHxV+STRDA19v35Q@mail.gmail.com>
Message-ID: <CANjZAi-cPnq3F4nk+voEaKftmx2PN=DS75Ar5UC8a-yfzoPWiw@mail.gmail.com>

I've associated it with vtk 8.0.1 and pv 5.4.1 to make sure we address it
asap.


David E DeMarle
Kitware, Inc.
Principal Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Tue, Jun 27, 2017 at 12:14 PM, Elvis Stansvik <
elvis.stansvik at orexplore.com> wrote:

> Den 27 juni 2017 4:58 em skrev "Sankhesh Jhaveri" <
> sankhesh.jhaveri at kitware.com>:
> >
> > The VTK maintenance team is happy to announce the eighth major release
> of VTK. Special thanks go out to everyone who tested and provided feedback
> and fixes during the release candidate cycle.
>
> Excellent, many thanks!
>
> It would be great if someone with the necessary bits could assign the
> Windows/Intel volume rendering bug I reported to a milestone:
>
> https://gitlab.kitware.com/vtk/vtk/issues/17058
>
> I can't seem to do it myself, but on vtk-developers I was told this would
> probably be worked on for the next point release.
>
> It means volume rendering in PV is currently broken on Windows +
> Haswell/Ivy Bridge, so I hope it's up there on the priority list.
>
> Elvis
>
> >
> > You can find the source, data and documentation tarballs on the VTK
> website. Please find detailed release notes here:
> https://blog.kitware.com/vtk-8-0-0/.
> >
> > As always, contact Kitware and the mailing lists for assistance.
> >
> > Thank,
> > VTK Maintenance Team
> >
> > ?
> > --
> > Sankhesh Jhaveri
> > Sr. Research & Development Engineer | Kitware | (518) 881-4417
> > ?
> >
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
> >
> > Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
> >
> > Search the list archives at: http://markmail.org/search/?q=vtkusers
> >
> > Follow this link to subscribe/unsubscribe:
> > http://public.kitware.com/mailman/listinfo/vtkusers
> >
>
> _______________________________________________
> 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/20170627/70f46ce8/attachment.html>

From elvis.stansvik at orexplore.com  Tue Jun 27 13:29:38 2017
From: elvis.stansvik at orexplore.com (Elvis Stansvik)
Date: Tue, 27 Jun 2017 19:29:38 +0200
Subject: [vtk-developers] [vtkusers] Announce: vtk 8.0.0 is ready!
In-Reply-To: <CANjZAi-cPnq3F4nk+voEaKftmx2PN=DS75Ar5UC8a-yfzoPWiw@mail.gmail.com>
References: <CAEcL5t4d2Xghno=m3MP=Vk0Oc4pwwXwW6ddP-rD00-HsgV-ZPw@mail.gmail.com>
 <CAE-7VJnixtfzXPWOfDgg_6KxAMntLcPznjMHxV+STRDA19v35Q@mail.gmail.com>
 <CANjZAi-cPnq3F4nk+voEaKftmx2PN=DS75Ar5UC8a-yfzoPWiw@mail.gmail.com>
Message-ID: <CAE-7VJk3dLEMemeXKVLMSVxWuRiHhz2-La7cPU4Wn5K7HUoMpQ@mail.gmail.com>

2017-06-27 18:19 GMT+02:00 David E DeMarle <dave.demarle at kitware.com>:
> I've associated it with vtk 8.0.1 and pv 5.4.1 to make sure we address it
> asap.

Thanks a lot.

Elvis

>
>
> David E DeMarle
> Kitware, Inc.
> Principal Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
> On Tue, Jun 27, 2017 at 12:14 PM, Elvis Stansvik
> <elvis.stansvik at orexplore.com> wrote:
>>
>> Den 27 juni 2017 4:58 em skrev "Sankhesh Jhaveri"
>> <sankhesh.jhaveri at kitware.com>:
>> >
>> > The VTK maintenance team is happy to announce the eighth major release
>> > of VTK. Special thanks go out to everyone who tested and provided feedback
>> > and fixes during the release candidate cycle.
>>
>> Excellent, many thanks!
>>
>> It would be great if someone with the necessary bits could assign the
>> Windows/Intel volume rendering bug I reported to a milestone:
>>
>> https://gitlab.kitware.com/vtk/vtk/issues/17058
>>
>> I can't seem to do it myself, but on vtk-developers I was told this would
>> probably be worked on for the next point release.
>>
>> It means volume rendering in PV is currently broken on Windows +
>> Haswell/Ivy Bridge, so I hope it's up there on the priority list.
>>
>> Elvis
>>
>> >
>> > You can find the source, data and documentation tarballs on the VTK
>> > website. Please find detailed release notes here:
>> > https://blog.kitware.com/vtk-8-0-0/.
>> >
>> > As always, contact Kitware and the mailing lists for assistance.
>> >
>> > Thank,
>> > VTK Maintenance Team
>> >
>> >
>> > --
>> > Sankhesh Jhaveri
>> > Sr. Research & Development Engineer | Kitware | (518) 881-4417
>> >
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Please keep messages on-topic and check the VTK FAQ at:
>> > http://www.vtk.org/Wiki/VTK_FAQ
>> >
>> > Search the list archives at: http://markmail.org/search/?q=vtkusers
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/vtkusers
>> >
>>
>>
>> _______________________________________________
>> 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
>>
>>
>

From rcourant at gmail.com  Tue Jun 27 13:42:05 2017
From: rcourant at gmail.com (Carlos Lopez)
Date: Tue, 27 Jun 2017 13:42:05 -0400
Subject: [vtk-developers] vtkFileOutputWindow and vtkCommand::MessageEvent
Message-ID: <CAL=MvspQ1vwBdhsof4U=QW2a-Bxz6D-MitFMsxGNEWi0v=JdHg@mail.gmail.com>

Hello there!

I'd like to ask if there is any reason vtkOutputWindow emits MessageEvent
when displaying text but fileOutputWindow doesn't.

also, what is the VTK way to send error messages when outside of a class
method, since vtkErrorMacro uses "this"?

thanks,
carlos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170627/9e87e472/attachment.html>

From ricardo_morello at hotmail.com  Tue Jun 27 18:27:30 2017
From: ricardo_morello at hotmail.com (Ricardo)
Date: Tue, 27 Jun 2017 15:27:30 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <1498555639546-5743791.post@n5.nabble.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
 <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
 <1498159865720-5743734.post@n5.nabble.com>
 <CAL=Mvsp=Mo2gfULdrdgoucpzytTgRgGXefOp7ik=c2QkXMfJrQ@mail.gmail.com>
 <1498171472336-5743737.post@n5.nabble.com>
 <1498186501910-5743740.post@n5.nabble.com>
 <1498555639546-5743791.post@n5.nabble.com>
Message-ID: <1498602450535-5743803.post@n5.nabble.com>

Hi! Could you please send a picture of your screen error? thanks!



--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731p5743803.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From ansha.kamath at gmail.com  Wed Jun 28 02:32:48 2017
From: ansha.kamath at gmail.com (anusha_kamath)
Date: Tue, 27 Jun 2017 23:32:48 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <1498602450535-5743803.post@n5.nabble.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
 <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
 <1498159865720-5743734.post@n5.nabble.com>
 <CAL=Mvsp=Mo2gfULdrdgoucpzytTgRgGXefOp7ik=c2QkXMfJrQ@mail.gmail.com>
 <1498171472336-5743737.post@n5.nabble.com>
 <1498186501910-5743740.post@n5.nabble.com>
 <1498555639546-5743791.post@n5.nabble.com>
 <1498602450535-5743803.post@n5.nabble.com>
Message-ID: <1498631568362-5743807.post@n5.nabble.com>

Hi!I was on windows 8.1 with cmake 3.3.0 and visual studio 2012.However the
error did not show up when i switched to windows 10 and all the other
versions u specified .
Thanks alot !!  



--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731p5743807.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From ansha.kamath at gmail.com  Wed Jun 28 03:13:22 2017
From: ansha.kamath at gmail.com (anusha_kamath)
Date: Wed, 28 Jun 2017 00:13:22 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <1498631568362-5743807.post@n5.nabble.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
 <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
 <1498159865720-5743734.post@n5.nabble.com>
 <CAL=Mvsp=Mo2gfULdrdgoucpzytTgRgGXefOp7ik=c2QkXMfJrQ@mail.gmail.com>
 <1498171472336-5743737.post@n5.nabble.com>
 <1498186501910-5743740.post@n5.nabble.com>
 <1498555639546-5743791.post@n5.nabble.com>
 <1498602450535-5743803.post@n5.nabble.com>
 <1498631568362-5743807.post@n5.nabble.com>
Message-ID: <1498634002916-5743808.post@n5.nabble.com>

But the following error occurs when cmakelists.txt file in
VTK-7.1.1\Rendering\OpenVR is given to cmake
<http://vtk.1045678.n5.nabble.com/file/n5743808/capture%283%29.png> 
<http://vtk.1045678.n5.nabble.com/file/n5743808/capture%284%29.png> 



--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731p5743808.html
Sent from the VTK - Dev mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20170628/f089df14/attachment.html>

From ansha.kamath at gmail.com  Wed Jun 28 03:28:18 2017
From: ansha.kamath at gmail.com (anusha_kamath)
Date: Wed, 28 Jun 2017 00:28:18 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <1498602450535-5743803.post@n5.nabble.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
 <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
 <1498159865720-5743734.post@n5.nabble.com>
 <CAL=Mvsp=Mo2gfULdrdgoucpzytTgRgGXefOp7ik=c2QkXMfJrQ@mail.gmail.com>
 <1498171472336-5743737.post@n5.nabble.com>
 <1498186501910-5743740.post@n5.nabble.com>
 <1498555639546-5743791.post@n5.nabble.com>
 <1498602450535-5743803.post@n5.nabble.com>
Message-ID: <1498634898377-5743809.post@n5.nabble.com>

Also the problem didnt seem to solve when openvr_dir was given the path
pointing to openvr_master folder
<http://vtk.1045678.n5.nabble.com/file/n5743809/capture%285%29.png> 

Thank you !!



--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731p5743809.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From bill.lorensen at gmail.com  Wed Jun 28 13:37:29 2017
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Wed, 28 Jun 2017 13:37:29 -0400
Subject: [vtk-developers] VTK Examples replace old WikiExamples as a remote
	module
Message-ID: <CADZJ4hNvaFqJgG4p2YxRXywaajLVMj=eHtPF8kodwcuP5XqiCA@mail.gmail.com>

Folks,

The new VTK examples now replaces the old Wiki examples remote module.
The module is still called WitkiExamples. If you have built this
remote module i the past, you will need to remove the
Remote/WikiExamples tree before rebuilding.

Bill

From ricardo_morello at hotmail.com  Wed Jun 28 14:29:08 2017
From: ricardo_morello at hotmail.com (Ricardo)
Date: Wed, 28 Jun 2017 11:29:08 -0700 (MST)
Subject: [vtk-developers] OpenVR HTC Vive
In-Reply-To: <1498634898377-5743809.post@n5.nabble.com>
References: <1498155691150-5743731.post@n5.nabble.com>
 <1498156482678-5743732.post@n5.nabble.com>
 <CAL=MvspVOb0Gmb=v-qx2=tUS1HoMEAaXCZ45_ZbZwt95EUWY5g@mail.gmail.com>
 <1498159865720-5743734.post@n5.nabble.com>
 <CAL=Mvsp=Mo2gfULdrdgoucpzytTgRgGXefOp7ik=c2QkXMfJrQ@mail.gmail.com>
 <1498171472336-5743737.post@n5.nabble.com>
 <1498186501910-5743740.post@n5.nabble.com>
 <1498555639546-5743791.post@n5.nabble.com>
 <1498602450535-5743803.post@n5.nabble.com>
 <1498634898377-5743809.post@n5.nabble.com>
Message-ID: <1498674548434-5743815.post@n5.nabble.com>

Well, congratulations then! That cmake warning means that it didn't find the
openvr path in your machine, so you have to manually setup it. Glad it
worked! Good luck!
Greetings from Brazil!



--
View this message in context: http://vtk.1045678.n5.nabble.com/OpenVR-HTC-Vive-tp5743731p5743815.html
Sent from the VTK - Dev mailing list archive at Nabble.com.

From utkarsh.ayachit at kitware.com  Thu Jun 29 09:40:02 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Thu, 29 Jun 2017 09:40:02 -0400
Subject: [vtk-developers] What is vtkRenderLargeImage?
Message-ID: <CADHSJjBeSZXFv_yJkNvh79mxYBRFBTKhWtbWT2F6tJxoxcJyCA@mail.gmail.com>

Folks,

I ran into `vtkRenderLargeImage` accidentally today. Seems to me it's
an old class that should be deprecated in lieu of
`vtkWindowToImageFilter`. Does anyone have any reason why not to do
that?

Thanks
Utkarsh

From mathieu.malaterre at gmail.com  Thu Jun 29 10:29:43 2017
From: mathieu.malaterre at gmail.com (Mathieu Malaterre)
Date: Thu, 29 Jun 2017 16:29:43 +0200
Subject: [vtk-developers] What is vtkRenderLargeImage?
In-Reply-To: <CADHSJjBeSZXFv_yJkNvh79mxYBRFBTKhWtbWT2F6tJxoxcJyCA@mail.gmail.com>
References: <CADHSJjBeSZXFv_yJkNvh79mxYBRFBTKhWtbWT2F6tJxoxcJyCA@mail.gmail.com>
Message-ID: <CA+7wUszFMfh6TCzpnE79W7yxbTHyOwgcGo-s4Zz+NNsKM6jB8Q@mail.gmail.com>

On Thu, Jun 29, 2017 at 3:40 PM, Utkarsh Ayachit
<utkarsh.ayachit at kitware.com> wrote:
> Folks,
>
> I ran into `vtkRenderLargeImage` accidentally today. Seems to me it's
> an old class that should be deprecated in lieu of
> `vtkWindowToImageFilter`. Does anyone have any reason why not to do
> that?

I believe vtkWindowToImageFilter cannot render in something larger
than the current window on the screen... well things may have changed
since.

From utkarsh.ayachit at kitware.com  Thu Jun 29 10:40:53 2017
From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit)
Date: Thu, 29 Jun 2017 10:40:53 -0400
Subject: [vtk-developers] What is vtkRenderLargeImage?
In-Reply-To: <CA+7wUszFMfh6TCzpnE79W7yxbTHyOwgcGo-s4Zz+NNsKM6jB8Q@mail.gmail.com>
References: <CADHSJjBeSZXFv_yJkNvh79mxYBRFBTKhWtbWT2F6tJxoxcJyCA@mail.gmail.com>
 <CA+7wUszFMfh6TCzpnE79W7yxbTHyOwgcGo-s4Zz+NNsKM6jB8Q@mail.gmail.com>
Message-ID: <CADHSJjAMT3UFd2xFeQFixZ8YMr3EaeWaNGD4doSF62rrqy7n+A@mail.gmail.com>

> I believe vtkWindowToImageFilter cannot render in something larger
> than the current window on the screen... well things may have changed
> since.

vtkWindowToImageFilter indeed supports `Magnification` (similar to
vtkRenderLargeImage)  which allows for rendering an image larger than
the current render window size.

Utkarsh

From shawn.waldon at kitware.com  Fri Jun 30 09:56:41 2017
From: shawn.waldon at kitware.com (Shawn Waldon)
Date: Fri, 30 Jun 2017 09:56:41 -0400
Subject: [vtk-developers] Is someone working on the bigmac failures?
In-Reply-To: <CANwS1=GfParPcP8weReq1OjuKD5sdo9dUWN1Vb8PzHhAE-1tCw@mail.gmail.com>
References: <CANXz0SYnT9Sp9ynhsPQTtRFGio3eZmQn2buCPZzqrtXwiQsG7Q@mail.gmail.com>
 <CAB5Fpx6nkaer1ASG_uhW3+3g_ft_kayQ+Wto7S87y-s+moTOVg@mail.gmail.com>
 <20170602155435.646162128@mail.rogue-research.com>
 <CANwS1=GfParPcP8weReq1OjuKD5sdo9dUWN1Vb8PzHhAE-1tCw@mail.gmail.com>
Message-ID: <CALSpCT1UQG27qxQoV57KXAEV4eGvP_EcY9xEt7w6Lu_j3m6UBQ@mail.gmail.com>

Ping?  Is anyone still working on this?

On Fri, Jun 2, 2017 at 12:01 PM, David Gobbi <david.gobbi at gmail.com> wrote:

> On Fri, Jun 2, 2017 at 9:54 AM, Sean McBride <sean at rogue-research.com>
> wrote:
>>
>>
>> Would it be hard / what would be involved in: changing all tests and
>> images to have an even number of pixels in width and height?  (Multiple of
>> 4 might be even more future-proof against future very HiDPI displays.)
>
>
> It would be easier to change the testing so that it tolerates a 1-pixel
> difference in the size in the images.  In the future the tolerance could be
> increased as necessary.
>
>  - 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/20170630/624d7a44/attachment.html>

From sce2020sahaf at yahoo.com  Fri Jun 30 10:43:48 2017
From: sce2020sahaf at yahoo.com (sepideh20)
Date: Fri, 30 Jun 2017 07:43:48 -0700 (MST)
Subject: [vtk-developers] Create custom frustum for vtkExtractGeometry
Message-ID: <1498833828154-5743836.post@n5.nabble.com>

Hello, 

I want to create a custom frustum using vtkplanes. That frustum would be
then used in vtkExtractGeometry to extract an area of an unstructured grid.
Now, my problem is how to create a custom frustum with 8 points (all the
corners of the frustum). In other words, using the 8 corner points that I
have, how should I set planes in SetFrustumPlanes as below: 

 vtkPlanes planes = vtkPlanes.New(); 
  planes.SetFrustumPlanes( ???? ); 

Thanks.



--
View this message in context: http://vtk.1045678.n5.nabble.com/Create-custom-frustum-for-vtkExtractGeometry-tp5743836.html
Sent from the VTK - Dev mailing list archive at Nabble.com.