[vtk-developers] Marking data modified

[Shawn Waldon]

Ok, so what should be added to the documentation on
vtkPolyData::ReplaceCell?

// This operation modifies one of the vtkCellArrays contained in this
vtkPolyData.  In order for this change to be picked up by the rendering
system, Modified() must be called on that vtkCellArray. (What goes here to
help them figure out which cell array to call Modified() on????)

I think that at least for now we have to change vtkPolyData::ReplaceCell to
either call Modified() on the correct vtkCellArray or return something to
indicate to the user which cell array they need to modify.  I lean toward
the first, and just add a line in the method's documentation saying that
this is not recommended for tight loops and to use ReplaceCell on the
vtkCellArrays if you need to change many cells in tight loops.  This method
is already doing lookups to determine which cell array to modify and a
switch to do it, which is not something you really want in tight loops.

Shawn

On Mon, Aug 15, 2016 at 3:17 PM, Will Schroeder <will.schroeder at kitware.com>
wrote:

> FYI- Just to provide more background context: there are several
> triangulation classes like vtkDelaunay2D, vtkQuadricDecimation, and
> vtkGreedyTerrainDecimation that routinely swap the diagonal of the
> quadrilateral consisting of two adjacent triangles (sharing an edge). The
> edge swap is done to improve the triangulation quality. As Dave and Berk
> indicated, this is considered an atomic operation performed in tight loops
> so it is expected that Modified() is called at the end.
>
> Best,
> W
>
> On Mon, Aug 15, 2016 at 12:54 PM, David Cole via vtk-developers <
> vtk-developers at vtk.org> wrote:
>
>> I don't specifically know the answer to this one, but in general,
>> these sorts of things are on purpose for performance in VTK.
>>
>> If you want to replace 100 (or even more) cells, you'd want
>> ReplaceCell NOT to call Modified, and just do it once at the end of
>> your bulk replacement. I'd be surprised if somebody chimed in and
>> contradicted this... so I would think just fixing the docs is the
>> right way to go here.
>>
>>
>> HTH,
>> David C.
>>
>>
>> On Mon, Aug 15, 2016 at 11:59 AM, Shawn Waldon <shawn.waldon at kitware.com>
>> wrote:
>> > Hi all,
>> >
>> > I have been tracking down a bug in the vtkBoxRepresentation where the
>> > selected face never updated.  The issue was that the widget was calling
>> > ReplaceCell on the vtkCellArray for the selected face polydata, but
>> never
>> > calling Modified() on the cell array (though it did call Modified() on
>> the
>> > polydata).  With the new OpenGL backend this matters.  The
>> documentation for
>> > ReplaceCell doesn't say that you have to do this afterward and the
>> writer of
>> > vtkBoxRepresentation used that documentation.
>> >
>> > So my question is this: why doesn't ReplaceCell mark the cell array as
>> > modified? Is this a bug or on purpose for performance reasons?  I will
>> > update the docs or fix ReplaceCell once I know which is wrong.
>> >
>> > Thank you,
>> > Shawn
>> >
>> > _______________________________________________
>> > 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
>>
>>
>
>
> --
> William J. Schroeder, PhD
> Kitware, Inc. - Building the World's Technical Computing Software
> 28 Corporate Drive
> Clifton Park, NY 12065
> will.schroeder at kitware.com
> http://www.kitware.com
> (518) 881-4902
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160815/aaebbce7/attachment.html>