[Paraview] vtkSMCollaborationManager::FollowUser(id) doesn't update view

[Sven Kramer]

Yes, all these timer loops in paraview are annoying. There is no platform
independent solution for registering callbacks on sockets, but for each
supported OS a clean solution exists, which you could implement. So, it is
doable, but requires more effort than what is usually put into paraview.
Additionally you wouldn't probably want a callback after each received
byte, but rather after each complete message. This is not possible in a
generic way with the present message construction.

You seem to be stuck with similar problems as I was. You may want to
consider Visit as an alternative. Visit has an active user and developer
community so that there are more than two people on the mailing lists who
can answer questions like yours. Most of Visit has evolved over the last
few years rather than the "don't touch if not necessary" long history of
paraview, so that it has a much more modern design. These are some of the
reasons why my supervisor convinced me to favour Visit even after I was
half way through my project.

2016-06-10 18:58 GMT+02:00 Peter Debuchev <peterdebuchev at gmail.com>:

> Ok, that doesn't sound as bad as I expected. But still, is it necessary to
> "poll" the socket, checking its "select" method?
> I am not familiar with the details of socket communication, but I expect
> it should be possible that the socket invokes some callback when a message
> arrives? Or does some of the VTK design contradict such socket callbacks?
>
> I found that it is always problematic performance-wise if more than a few
> timers are running on one cpu.
>
> Peter
>
> 2016-06-10 15:17 GMT+02:00 Utkarsh Ayachit <utkarsh.ayachit at kitware.com>:
>
>> ProcessEvents() doesn't poll the server. It only "select"s on the
>> socket to see if the server sent any new messages to the client.
>>
>> > One more question out of curiosity: isn't it quite ineffient, if clients
>> > continuously invoke vtkNetworkAccessManager::ProcessEvents´()? For
>> smooth
>> > interaction this has to happen at least 10 times per second, which
>> causes a
>> > lot of network traffic by polling the server again and again,
>> especially if
>> > more than one client connects to the same server.
>> > Isn't it possible to react on incoming server events by registering a
>> > callback that does the same server event processing only when a new
>> event
>> > has occurred? I mean, all of VTK and ParaView is event based, why not
>> the
>> > server message processing?
>> >
>> > Peter
>> >
>> > 2016-06-09 18:29 GMT+02:00 Utkarsh Ayachit <utkarsh.ayachit at kitware.com
>> >:
>> >>
>> >> Here's the fix:
>> >>
>> >> diff --git a/main.cxx b/main.cxx
>> >> index dd47991..0f679ba 100644
>> >> --- a/main.cxx
>> >> +++ b/main.cxx
>> >> @@ -65,7 +65,7 @@ int main(int argc, char* argv[]){
>> >>    vtkSMSessionProxyManager* pxm = session->GetSessionProxyManager();
>> >>
>> >>    //Collaboration:
>> >> -  vtkSMCollaborationManager
>> >> *collaboration=vtkSMCollaborationManager::New();
>> >> +  vtkSMCollaborationManager *collaboration=
>> >> session->GetCollaborationManager();
>> >>    collaboration->SetSession(session);
>> >>    collaboration->UpdateUserInformations();
>> >
>> >
>>
>
>
> _______________________________________________
> 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 ParaView Wiki at:
> http://paraview.org/Wiki/ParaView
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20160615/44a36a89/attachment.html>