[vtkusers] vtkPoints.SetPoints bug?

[Fahlgren, Eric]

Using InsertPoint alone instead of SetPoint+Modified also pings the modified time, which brings us to an interesting side point.

We apparently had avoided InsertPoint due to performance issues in the past, so I benchmarked them and InsertPoint is now about 10% faster than SetPoint (which seems odd, since you’d think InsertPoint would be doing some extra mallocs that are clearly ☺ more expensive than simple indexing).  Maybe the extra data marshalling for the id parameter is the difference?

from tools.timethis import timethis
import vtk

nPts = 5
points = vtk.vtkPoints()

for iteration in range(21):
    print(f'{iteration:3d} {nPts:9_d}')

    with timethis('Insert'):
        points.SetNumberOfPoints(0)
        for i in range(nPts):
           x = y = z = float(i)
            points.InsertNextPoint(x,   y,   z)
            points.InsertNextPoint(x+1, y+2, z+3)

    with timethis('Set'):
        points.SetNumberOfPoints(nPts * 2)
        for i in range(nPts):
            id = i*2
            x = y = z = float(i)
            points.SetPoint(id+0, x,   y,   z)
            points.SetPoint(id+1, x+1, y+2, z+3)
        points.Modified()

    nPts *= 2


  0         5
  1        10
  2        20
...
18 1_310_720
19 2_621_440
20 5_242_880
Insert :   0.367240s : N=   21 : stddev=0.89898
Set    :   0.417269s : N=   21 : stddev=1.01908


From: vtkusers [mailto:vtkusers-bounces at public.kitware.com] On Behalf Of Fahlgren, Eric
Sent: Sunday, November 25, 2018 10:01 AM
To: David Gobbi
Cc: vtkusers at public.kitware.com
Subject: Re: [vtkusers] vtkPoints.SetPoints bug?

Thanks, David, that fixes it.  I’m pretty surprised at this since the code was actually written back in the 5.2 days and hasn’t been touched since…

Eric

From: David Gobbi [mailto:david.gobbi at gmail.com]
Sent: Sunday, November 25, 2018 8:25 AM
To: Fahlgren, Eric
Cc: vtkusers at public.kitware.com
Subject: Re: [vtkusers] vtkPoints.SetPoints bug?

Hi Eric,

It's necessary to call Modified() after calling SetPoint() in order for ComputeBounds() to re-compute the bounds.  This is because ComputeBounds() checks the timestamp and does nothing if the timestamp shows that the previous bounds are still good.

As far as I understand, vtkPoints has behaved this way for many years. Recently, however, there have been many changes to the VTK rendering pipeline that increase the reliance on timestamps. Perhaps in VTK 8.0 something was triggering a Modified() call or was otherwise forcing a re-computation of the bounds.

  David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtkusers/attachments/20181125/380b9035/attachment.html>