Why does looping through and visualizing point clouds lag the PCL visualizer?

Question

Here's the problem. I have an vector of point clouds pointers that I want to visualize one at a time. What I have is a visualizer that looks at the first spot in the vector and waits for keyboard inputs to change what is being visualized. For example, 'n' will give the visualizer the next element in the vector and 'b' will give you the previous one.

//n moves to the next frame
    if(event.getKeySym () == "n" && event.keyDown ()){
        moveForward();
    }

    //b goes back a frame
    if(event.getKeySym () == "b" && event.keyDown ()){
        if (current_spot > 0){
            newCloud(--current_spot); 
            viewer->updateText("Frame: " + std::to_string(--current_frame), TEXT_X, TEXT_FRAME_Y, "fileNum");
        }
    }

This allows you to go back and forth through the array and look at certain frames of the point cloud. This works well, however I have another key, 'm' that plays the frames like a video. It does this by creating a while loop and inside that, moving the frame forward, updating the visualizer, and sleeping to support frame rates.

//m plays all point clouds from current frame
    if(event.getKeySym () == "m" && event.keyUp ()){
        play = true;
        while(moveForward() && play) { 
            viewer->spinOnce(10);
            std::this_thread::sleep_for(std::chrono::milliseconds(22));
        }
    }

And here is the moveForward() and newCloud() function:

bool moveForward(){
    if(current_spot < BUFFER_LIMIT || (PC_Done && current_spot < DEQUE_SIZE - 1)){
        newCloud(++current_spot);
        viewer->updateText("Frame: " + std::to_string(++current_frame), TEXT_X, TEXT_FRAME_Y, "fileNum");
        return true;
    }else if(current_spot == BUFFER_LIMIT){
        clouds.pop_front();
        signalPC.notify_one();
        newCloud(current_spot);
        viewer->updateText("Frame: " + std::to_string(++current_frame), TEXT_X, TEXT_FRAME_Y, "fileNum");
        return true;
    }
    return false;
}

void newCloud(int spot){
    viewer->removePointCloud("cloud");
    viewer->addPointCloud(clouds[spot]);
    viewer->setPointCloudRenderingProperties (pcl::visualization::PCL_VISUALIZER_POINT_SIZE, 3, "cloud");
}

This works as intended by after it reaches the end or is stopped prematurely, the visualizer lags on all other inputs to move the camera or the frames and to make it worse, it stacks. The move you hit 'm', the more visualizer lags. Whats odd is that holding 'n' to move forward doesn't break anything while using 'm' does. Anyone have any ideas as to why this kill performance so much?

UPDATE

So it turns out that the overall lag of the visualizer stemmed from spin loop. I was using spinOnce(x) and then sleeping, which was a bit redundant and seemed to delay inputs because it was sleeping and storing inputs thus leading to sticky inputs. I got rid of the sleep and changed spinOnce(x) to spin() which made the inputs a lot smoother. However this did not entirely solve the video playback feature. I still needed to spinOnce() in that loop in order to 1. Actually update the visualizer after each new frame and 2. simulate a framerate. This leads to some odd effects. Using the movie function once will slow everything down significantly, however it doesn't stack after it is stopped, in fact it does the opposite. Pressing the 'm' key again will then revert everything to normal and play the video at the proper rate and stopping it will leave the visualizer in a optimal state. This will go back and forth and is quite odd. So I'll be working on that. If you have any ideas please let me know. Thanks!

Also here is the new 'm' press function:

//m plays all point clouds from current frame
    if(event.getKeySym () == "m" && event.keyUp ()){
        play = true;
        while(moveForward() && play) { 
            viewer->spinOnce(33);
        }
    }

Answer 1

Figured it out... So it turns out that the m key is bound to something in vtk. I looked through the pcl source code and I couldn't find any functionality bound to m so I'm at a loss for why exactly it was the m key specifically slowing down the visualizer. I simply moved my keybind off m and now it works perfectly. Pressing m still seems to cause bad effects though, got no clue on that. I know this is such a niche problem but I hope someone either gets a kick out of this or maybe, just maybe, this could help someone.

Answer 2

It looks like the 'm' key is bound in the VTK code base in "vtkInteractorStyle.cxx" to make a call to:

this->StartAnimate();

StartAnimate() appears to start a timer and force the vtkRenderWindowInteractor to render.