[vtkusers] animation while renderer responsive

[Ken Martin]

Elvis is right. Load the data, Update() the reader/pipeline (which forces
the pipeline to actually run). You can even create the mapper/actor etc if
you want. All in another thread. But adding the actor to the renderer and
rendering must be done in the main thread and there will be a pause as the
graphics objects get built and uploaded to the GPU but at least it will be
shorter as the file IO etc has already been done.

Some of the building of the graphics objects could also be done in the
other thread with some (possibly significant) coding changes to VTK which
would further reduce any hiccups.


On Wed, May 9, 2018 at 10:26 AM, Elvis Stansvik <
elvis.stansvik at orexplore.com> wrote:

> 2018-05-09 16:09 GMT+02:00 Sam Raby <rabysam28 at gmail.com>:
> > Hello, I have a vtkPolyData that I can display fine. Every half a second
> > another vrkplydata comes in, so I need to display the new vtkpolydata
> > instead of the old one, and so forth. It is essentially like an animation
> > but the incoming vtkploydata are different in size and content, so I
> cannot
> > use the same vtkpolydata object every time.
> >
> > Is there an example so I see how to approach this? One requirement is
> that
> > as this animation is displayed I need to be able to still interact with
> the
> > scene such as zoom in and out. So it needs to be an unblocking call.
>
> I think that everything up to the AddActor(..) and Render() calls on
> the renderer can be made in a different thread. But the AddActor(..)
> and Render() calls must be made from the main (GUI) thread (please
> someone correct me if I'm wrong).
>
> So your GUI will be blocked for some time, depending on how much time
> those two calls take for your polydata.
>
> In our application we also have this problem, but we're working with
> volumes (not polydata). The GUI should ideally be fully responsive
> while a volume is being added to the renderer, but it will freeze for
> some hundred ms or so. I don't think there's a way around this. We do
> the reading/creation of the volume pipeline in a separate thread, but
> still the adding of the volume to the renderer and the subsequent
> first render will take some time.
>
> Elvis
>
> >
> > Thanks
> > -s
> >
> > _______________________________________________
> > 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
> >
> > Search the list archives at: http://markmail.org/search/?q=vtkusers
> >
> > Follow this link to subscribe/unsubscribe:
> > https://vtk.org/mailman/listinfo/vtkusers
> >
> _______________________________________________
> 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
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtkusers
>



-- 
Ken Martin PhD
Distinguished Engineer
Kitware Inc.
101 East Weaver Street
Carrboro, North Carolina
27510 USA

This communication, including all attachments, contains confidential and
legally privileged information, and it is intended only for the use of the
addressee.  Access to this email by anyone else is unauthorized. If you are
not the intended recipient, any disclosure, copying, distribution or any
action taken in reliance on it is prohibited and may be unlawful. If you
received this communication in error please notify us immediately and
destroy the original message.  Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtkusers/attachments/20180509/0852e3f0/attachment.html>