[vtk-developers] Marking data modified

[Shawn Waldon]

See the example script on this bug report:
https://gitlab.kitware.com/vtk/vtk/issues/16812.  It is calling Modified()
on the polydata, but to actually see the updated geometry, you have to add
pdata.GetPolys().Modified().  And I can only say that for sure because I
know the cell in question is polygonal.  ReplaceCell doesn't tell the
caller which cell array needs to be updated.

Shawn

On Mon, Aug 15, 2016 at 2:36 PM, Berk Geveci <berk.geveci at kitware.com>
wrote:

> Can you provide a bit more detail? Who's MTime is important in this case?
> Note that vtkPolyData does not take into account the MTime of the
> underlying vtkCellArrays when computing its own MTime. So if the MTime of
> the polydata is becoming stale, simply calling Modified() on it should be
> sufficient. As far as I can tell, vtkCellArray does nothing with MTime.
>
> On Mon, Aug 15, 2016 at 1:25 PM, Shawn Waldon <shawn.waldon at kitware.com>
> wrote:
>
>> Thanks David & Berk,
>>
>> Ok, I'll add a commit to my branch to update the docs and add you as
>> reviewers.  I have a follow-up question though:  vtkPolyData::ReplaceCell.
>> This function figures out which cell array the cell is in and then calls
>> ReplaceCell on that one.  It can be in Verts, Lines, Polys, or Strips.  So
>> the caller may not know which cell array to call Modified on.  What should
>> we do in this case?
>>
>> Shawn
>>
>> On Mon, Aug 15, 2016 at 12:55 PM, Berk Geveci <berk.geveci at kitware.com>
>> wrote:
>>
>>> I agree with David.
>>>
>>> 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
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160815/64e775ae/attachment-0001.html>