PCLVisualizer::spinOnce, 15ms latency / blocking problem

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PCLVisualizer::spinOnce, 15ms latency / blocking problem

srwilton
This post was updated on .
I've been using PCL for quite some time to process and visualize point clouds.  Typically, my point cloud display rate is ~10 Hz (100 ms between images), so I have not needed the point clouds to render very fast.  Now, it is becoming increasingly more important to render the point clouds with the minimum possible latency since my sensor is capable of generating point clouds at rates greater than 120 Hz.  It is not necessarily important to display the point clouds at 120 Hz on screen, but I need the blocking time of spinOnce to be as small as possible to prevent stuttering.  Right now, I am measuring about 15 ms of latency for each call to spinOnce that actually draws the point cloud.

Currently, the vtkRenderWindowInteractor is forced to 30 Hz update rate in the PCLVisualizer source code via interactor_->setDesiredUpdateRate(30), which cannot be modified because it is not exposed in the object interface and the vtkRenderWindowInteractor is a private member.  I looked at the VTK documentation to try to understand this parameter, but the description was quite vague.  Just out of curiosity, I modified the PCL source code (header) and exposed the vtkRenderWindowInteractor as a public member, then modified the setDesiredUpdateRate value of the interactor to see how it affected the program's behavior.  After successfully setting this value to a very small number (e.g. 0.001), now my render latency is ~1 millisecond when I call PCLVisualizer::spinOnce(1, true) with no perceived change in how I can interact with the point cloud.  So effectively I can get 120 Hz display rate with 15x less blocking time.

I am curious if anyone can help me to understand what the value of setDesiredUpdateRate actually does, and why it takes so long to render the point cloud in PCLVisualizer when the update rate is higher.  From my perception, the value setpoint of setDesiredUpdateRate doesn't affect anything w.r.t. my output display, aside from a change in blocking latency which does not correspond to the setpoint.  Since I just hacked my way to a solution without understanding the real underlying problem, I am wondering if anyone here has insight about what is going on.

edit: also, is there any way to prevent the vtkRenderWindow from blocking when the user is rotating or zooming?  In other words, I want to keep updating the screen while the user is interacting with the visualizer output window with the mouse.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PCLVisualizer::spinOnce, 15ms latency / blocking problem

ioannis
Hi srwilton,

did you find the answer for this?:
srwilton wrote
also, is there any way to prevent the vtkRenderWindow from blocking when the user is rotating or zooming?  In other words, I want to keep updating the screen while the user is interacting with the visualizer output window with the mouse.
I'm interested in this too.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PCLVisualizer::spinOnce, 15ms latency / blocking problem

srwilton
This post was updated on .
hi ioannis,

I did not find a way to do exactly what I wanted to do, but I found a compromise.  Ideally, I desire two things while the left mouse-button is clicked: (1) non-blocking behavior with respect to the rest of my program (2) non-blocking behavior with respect to rendering.

Number 1, I did solve, but it is actually quite a nightmare. Oddly vtk does not allow multiple threads to ever access a PCLVisualizer.  Mutexes and any kind of signaling / synchronization behavior do not help; it's not related to race conditions, but the inherent architecture of vtk.  Long story short, the only possible way to achieve multithreading behavior with a PCLVisualizer is to create a new thread, create a PCLVisualizer inside of that thread, and loop it until you want to exit the visualizer.  

The problem is that all calls to the PCLVisualizer must happen inside of the same thread that it was created in, so you need to create a signaling mechanism to indirectly communicate between main and the PCLVisualizer inside of that thread.  My workaround for this is to wrap PCLVisualizer inside a new class, and have a member function 'void push(std::function)' that pushes the std::function into a queue which the visualizer thread flushes once per loop.

Number 2 is the holy grail, < 2 ms render time, non-blocking mouse interactor.  I still play around with this issue from time to time, but I'm almost certain it requires modification of source code... which is fine, but the documentation for VTK on this issue is really bad.  A workaround that I play with in my spare time is to register a custom keyboard interactor that allows the user to toggle a keyboard/mouse movement mode.  In this mode, the mouse will always be tracked without holding down the left mouse button, and I will have a toggle between orbit mode (PCL default) and linear mode (normal movement like a game).

If you ever find a way to solve this problem directly, I would be very interested to learn how.  If I find a direct fix, I'll be sure to post a message.
Loading...