[vtkusers] Render function's in-deterministic performance

[David Gobbi]

Hi Siddharth,

There is a lot that goes on when you call renwin->Render(), so there
is no simple answer to your question.  The Render() call is delegated
to each Renderer, and then from the Renderer to the Props, and from
each Prop to that Prop's Mapper, which will update its input
connection and then perform the OpenGL calls.

You can time the Update portion separately by calling Update() on all
the mappers (or on the mapper inputs) before calling renwin->Render().
 If you know how long each update takes, it might give you some clues.
 A second option is to use a profiler.

You say you are using multiple threads: depending on how you use the
mutex locks, you can have one thread blocking the other thread(s) in
non-deterministic ways.  The same often happens with IO, a program
will generally be blocked until IO calls are done.  So you have to be
very careful when you are doing your timing.

 - David


On Tue, Dec 13, 2011 at 11:51 PM, Siddharth Vikal
<siddharthvikal at gmail.com> wrote:
> I've tried the suggestions from Sebastien and Navneeth i.e. upgrading to VTK
> 5.8, and calling modified, however the problem remains unsolved.
>
> Any insights into why 'render' should behave erratically? The rendering time
> alone, measured before and after call of renwin->render is varying from 6-7
> msecs at most times to 50-60 msecs at other times!
>
> David, any thoughts?
>
> regards,
> Siddharth
>
>
> On Tue, Dec 6, 2011 at 10:17 PM, Navneeth Subramanian <navneeth.s at gmail.com>
> wrote:
>>
>> Hi Siddharth,
>> Perhaps you are seeing a race-condition between the camera capture
>> thread & the vtk render thread ?
>> Can you force call ->Modified() on the vtkImageData object at the end
>> of the camera refresh to see if that helps.
>>
>> best,
>> navneeth
>>
>> > ------------------------------
>> >
>> > Message: 16
>> > Date: Tue, 6 Dec 2011 19:35:52 +0530
>> > From: Siddharth Vikal <siddharthvikal at gmail.com>
>> > Subject: [vtkusers] Render function's in-deterministic performance
>> > To: vtkusers at vtk.org
>> > Message-ID:
>> >
>> >  <CADM22yxyGDvhiWBogiqTV7M5B_ZExryetZCQzSxPn6jwGRhjPw at mail.gmail.com>
>> > Content-Type: text/plain; charset="iso-8859-1"
>> >
>> > Hi,
>> >
>> > Let me first describe the set-up. I'm using a quad core, linux box with
>> > vtk
>> > 5.4. I'm using Qt for GUI, thus QVTKWidget. I'm trying to visualize
>> > image
>> > frames (1280 x1280 pixels) being captured from a camera device. The
>> > anticipated frame rate is 30 fps. I've 'capture frame' functionality
>> > happening in a separate thread. A minimal vtk pipeline is set up using
>> > vtkImageData, vtkImageMapper, vtkActor2D. Each time a new frame arrives,
>> > update is callled on the vtk pipeline and the main thread running Qt, is
>> > notified to perform render operation using paint event of QVTKWidget.
>> > For
>> > synchronization, mutex is used. This setup seems to work just fine
>> > except
>> > from the performance predictability standpoint.I've put timers in place
>> > to
>> > measure time taken for each step.
>> >
>> > The problem is, the paint call (or eventually 'render' call) is not
>> > behaving deterministically. For some frames, render completes within
>> > 6-10
>> > milliseconds, but for others, inexplicably, it starts taking 50-70
>> > milliseconds!! Now with new frame arriving at every 33 milliseconds (30
>> > fps), I start loosing frames. I've tried the setup using vtkImageActor
>> > (therefore without vtkImageMapper, vtkActor2D) as well, but with similar
>> > behavior.
>> >
>> > I don't understand why is render taking 60-70 milliseconds? The data is
>> > ready to be rendered. The in-deterministic aspect is even more worrying.
>> >
>> > Can someone please help? It'll be greatly appreciated.
>> >
>> > regards
>> > Siddharth
>> > -------------- next part --------------
>> > An HTML attachment was scrubbed...
>> > URL:
>> > <http://www.vtk.org/pipermail/vtkusers/attachments/20111206/339c44b8/attachment-0001.htm>
>> >
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtkusers
>