[vtkusers] 3 speed questions

[Karthik Krishnan]

On Tue, Nov 9, 2010 at 2:54 AM, Jonathan Morra <jonmorra at gmail.com> wrote:
> More information that I've found about the first issue I reported.  I've
> been narrowing down the issue, and the issue appears to be with
> vtkImageViewer2.SetSlice(int slice).  This method is very slow when I'm
> rendering a vtkPolyData that represents a mesh (whether it's cut or not is
> actually irrelevant)

Contrary to what you assume, It is relevant. The SetSlice method
internally invokes render, so as to update the display in response to
changes. A "Render" implies that everything displayed on this
renderwindow is re-rendered. This includes the rendering the polydata.
If uncut, it can be slow depending on the number of cells. If cut, it
can take time to update the cutter, since the cut-function (plane) has
been translated.

> and fast when I'm rendering either nothing or a
> vtkPolyData that represents a stack of 2D contours.  Does this help at all?

Indeed, as mentioned above, there is no cutting to perform here.
Rendering a bunch of 2D contours is probably faster than rendering
your entire mesh.

>
> On Mon, Nov 8, 2010 at 10:26 AM, Jonathan Morra <jonmorra at gmail.com> wrote:
>>
>> Thanks for your response.  It turns out on my machine that that
>> initialization is too slow.  What's happening is the following
>> 1.  The user click indicating that they want to try a contour
>> 2.  A new vtkContourWidget is made with the dijkstra interpolator.
>> 3.  The contour widget is initialized as I described above with just two
>> points.  Adding that second point is where the slowdown occurs.
>> As far as point 2, I am initializing a contour widget with the output of
>> vtkCutter, but I am subsampling when I do that (I take 7% of the points), so
>> I only have a handful of control points.  Is there a way to frontload the
>> load time so I only have to do it once as opposed to every time a user wants
>> to draw a contour?  That is simply too slow for my application.
>> Also do you have any idea why rendering the meshes is slow?  Could it be
>> related to the point order, or is is something else?
>> On Sat, Nov 6, 2010 at 8:54 AM, Karthik Krishnan
>> <karthik.krishnan at kitware.com> wrote:
>>>
>>> On Tue, Nov 2, 2010 at 6:31 AM, Jonathan Morra <jonmorra at gmail.com>
>>> wrote:
>>> > on vtkDijkstraImageContourLineInterpolator and am able to successfully
>>> > create the contour widget with live wire interpolation. However, when I
>>> > first initialize the contour with the following code it is very slow
>>> >     // For now, we're just initializing the data with
>>> >     // the point that was clicked
>>> >     vtkPoints points = new vtkPoints();
>>> >
>>> >     // The initial data MUST be at least a "line"
>>> >     // by giving the same point twice we are effictively creating a
>>> > zero
>>> >     // length line
>>> >     points.InsertNextPoint(lastContourControlPoint);
>>> >     points.InsertNextPoint(lastContourControlPoint);
>>> >     vtkPolyData initialData = new vtkPolyData();
>>> >     initialData.SetPoints(points);
>>> >     contourWidget.Initialize(initialData, 0);
>>> > The line that is slow is the last line.  The weird part is that if I do
>>> > not
>>> > use live wire, and just use the default Bezier curve interpolation the
>>> > initialization is instant.
>>>
>>> Yes. There are 2 issues here.
>>>
>>> 1. The dijkstra interpolator is a bit slow to start with, since during
>>> the time of initialization, it builds the adjacency information. But
>>> that's not a big deal when you are drawing on an image. The very first
>>> line segment placement is a bit slow (~3 seconds). After that its fast
>>> and interactive.
>>>
>>> 2. The real issue, I think, here is the fact that you are initializing
>>> the contour with the contour with lots of control points. How many of
>>> them are there ? As I understand, you are generating these control
>>> points from the output of vtkCutter ? Perhaps you want to sample the
>>> input polyline and then feed those sample points as the control
>>> points.
>>>
>>> Thanks
>>> --
>>> karthik
>>
>
>