[vtkusers] animation while renderer responsive

[Elvis Stansvik]

2018-05-10 14:26 GMT+02:00  <aborsic at ne-scientific.com>:
> Hi Ken, Elvis,
>
>
>
> I have one question: the VTK User’s Guide covers in detail multithreading
> approaches based on streaming datasets across different execution paths. I
> am not aware (and perhaps I am mistaken) of a unified discussion /
> documentation for approaches to parallelism where parts of a pipeline are
> executed by different threads, as in the case discussed here.
>
>
>
> Am I wrong in this? Is there any documentation / resource that you would
> suggest reading? For example, where is it possible too find the requirement
> that the AddActor() and Render() calls should be made by the main thread?

I've also looked for some page that summarizes "all things related to
multithreading" in VTK in the past (what's safe, what's not et.c.),
but haven't found it.

The approach I've taken is to assume that things are not thread-safe
in general, unless otherwise noted, since it's quite some work to make
things thread-safe.

Regarding the info that you can construct your pipeline and execute it
(using Update()) to obtain a result, and then hand that result off to
the main thread, but that the AddActor(...) and Render(..) must run on
the main (GUI) thread, well I think I may have found that bit of info
in some other mail thread, or maybe I just tried it and assumed it
would work :) But yes, it would be great if it was officially
documented somewhere.

Note that individual algorithms in a pipeline may use multithreading
internally to do their work (and in fact many VTK filters do), so
parts of a pipeline may be multi-threaded internally, but I don't
think the pipeline machinery itself is thread-safe. E.g. you can't
have a pipeline that straddle thread boundaries (again, someone
correct me if I'm wrong).

Elvis

>
>
>
> Thanks for any advice,
>
>
>
> Best Regards,
>
>
>
> Andrea
>
>
>
>
>
>
>
> From: vtkusers <vtkusers-bounces at vtk.org> On Behalf Of Ken Martin
> Sent: Wednesday, May 9, 2018 11:07 AM
> To: Elvis Stansvik <elvis.stansvik at orexplore.com>
> Cc: VTK Users <vtkusers at vtk.org>
> Subject: Re: [vtkusers] animation while renderer responsive
>
>
>
> 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.