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

[Peter Debuchev]

I don't find anything constructive in your answer. If you think paraview
sucks, I don't care if you discuss it in your own thread. But I am of a
different opinion and I prefer positive discussions, so please stop it here.

Peter

2016-06-15 7:34 GMT+02:00 Sven Kramer <svenkramer40 at gmail.com>:

> 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/849f966d/attachment.html>