[vtk-developers] Changes to the way the pipeline is updated

[Berk Geveci]

> 1) Did you mean to commit that commented code in
Accelerators/Piston/vtkPistonMapper.cxx ?

Kind of :-) Piston is not moving forward because it was replaced by VTK-m.
So before VTK 8, we will yank the Piston module out. That was quick (and
dirty) way of making it compile with my changes. It is not worth the effort
to make it work at this point.

> do I understand correctly that I can now just do:
>
> slicer->UpdateWholeExtent();

Yes. I didn't add this API btw. It was already there.

>>Here is the branch that passes all of the tests:
>>
>>https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change
>
> Shame that link is dead just 6 weeks later.  Makes it harder to research
what/when changes broke things... :(

That's totally my bad. I pointed to the branch on my fork and then deleted
the branch after the merge. Here is the permanent link:

https://gitlab.kitware.com/vtk/vtk/merge_requests/1090

Best,
-berk

On Tue, Mar 1, 2016 at 12:39 PM, Sean McBride <sean at rogue-research.com>
wrote:

> On Fri, 15 Jan 2016 10:57:36 -0500, Berk Geveci said:
>
> >In an effort to address a bug reported on the mailing list, I ended up
> >making a change to the way the pipeline is updated. I made a minor change
> >to the way update behaves but more importantly, I'd like to make an API
> >change that is biggish.
>
> Berk,
>
> After rebuilding my app with VTK master I've run into this.
>
> I just went through the change with git show f020ebb6 and had 2 comments
> on the code change:
>
> 1) Did you mean to commit that commented code in
> Accelerators/Piston/vtkPistonMapper.cxx ?
>
> 2)
>
> +The following new methods were added:
> +
> +### vtkAlgorithm:
> +
> +    int Update(int port, vtkInformationVector* requests);
> +    int Update(vtkInformation* requests);
> +    int UpdatePiece(int piece, int numPieces, int ghostLevels, int*
> extents=0);
> +    int UpdateExtent(int piece, int numPieces, int ghostLevels, int*
> extents=0);
> +    int UpdateTimeStep(double time,
> +        int piece=-1, int numPieces=1, int ghostLevels=0, int* extents=0);
>
> Couldn't those 'extents' params be const?  I know many VTK API are not
> very const friendly, but seems a shame to perpetuate that with new API.
>
> >Here is how an algorithm is updated currently.
> >
> >anAlgorithm->Update();
> >
> >If you want the algorithm to produce a particular subset in space or time,
> >you need to do this:
> >
> >anAlgorithm->UpdateInformation();
> >anAlgorithm->SetUpdateExtent(0, 2, 0);
> >anAlgorithm->SetUpdateExtent(0, 10, 0, 10, 1, 1);
> >anAlgorithm->SetUpdateTimeStep(0.5);
> >anAlgorithm->Update();
>
> My app has a few of this pattern:
>
>  slicer->UpdateInformation();
>  slicer->SetUpdateExtentToWholeExtent();
>  slicer->Update();
>
> do I understand correctly that I can now just do:
>
>  slicer->UpdateWholeExtent();
>
> >Here is the branch that passes all of the tests:
> >
> >https://gitlab.kitware.com/berkgeveci/vtk/commits/setupdateextent-change
>
> Shame that link is dead just 6 weeks later.  Makes it harder to research
> what/when changes broke things... :(
>
> Thanks,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montréal, Québec, Canada
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160301/1427ae33/attachment-0001.html>