Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OSX VTK6 PCLVisualizer::wasStopped() behavior #1390

Closed
SergioRAgostinho opened this issue Oct 20, 2015 · 12 comments
Closed

OSX VTK6 PCLVisualizer::wasStopped() behavior #1390

SergioRAgostinho opened this issue Oct 20, 2015 · 12 comments

Comments

@SergioRAgostinho
Copy link
Member

Hi all,

PCLVisualizer::wasStopped() is described in the documentation as "Returns true when the user tried to close the window.". From various comments around the web, the intended behaviour seems to be for the method to return true when the user presses the 'x' corner button of the window.

I'm working with OS X 10.10 and vtk6.2 and this is not working for me. When I close the window, PCLVisualizer::wasStopped() still returns false and my console then get's polluted with the following message

ERROR: In /tmp/vtk20150617-7180-8mym6w/VTK-6.2.0/Rendering/OpenGL/vtkOpenGLPolyDataMapper2D.cxx, line 442
vtkOpenGLPolyDataMapper2D (0x7fe94bd15170): failed after RenderOverlay 1 OpenGL errors detected
  0 : (1286) Invalid framebuffer operation

After some digging I found this mention in VTK's documentation for vtkRenderWindow::IsDrawable() acknowledging the issue with Cocoa.
I managed to correct this behavior by getting the smart pointer to the vtkRenderWindow and adding the additional check to vtkRenderWindow::IsDrawable().

Would it not be best to add this additional check into PCLVisualizer::wasStopped()?

My tests were limited to console apps.

@taketwo
Copy link
Member

taketwo commented Oct 21, 2015

If IsDrawable() returns false, does this necessarily mean that the visualizer was stopped (on all platforms)?

@SergioRAgostinho
Copy link
Member Author

In this source, it seems to indicate that if you don't have visible (open?) drawable window for vtk to render on, the condition will trigger.

On OS X, if you press the 'x' button, the window will close, triggering the condition.
On Linux, I'll need to try over the weekend, but the note @VictorLamoine added on this bug report, seem to suggest the condition will also be triggered.
I don't have a Windows environment to test this.

@SergioRAgostinho
Copy link
Member Author

vtkRenderWindow::IsDrawable()was only introduced in vtk6.1 and pcl still supports vtk5.x.

@taketwo
Copy link
Member

taketwo commented Oct 26, 2015

We have quite a few conditionally compiled sections here and there to support both versions. So it's fine to add something that exists only in newer versions, given that we properly surround it with #if guards.

@SergioRAgostinho
Copy link
Member Author

This seems to be Mac specific. On a Ubuntu system with vtk6.2, I tried probing the result from win_->IsDrawable() in both pcl::visualization::PCLVisualizer::wasStopped () and more importantly in pcl::visualization::PCLVisualizer::ExitCallback::Execute() at the end of the function and it always reports true.

@SergioRAgostinho
Copy link
Member Author

Hey, I want to start working on a fix for this.

My idea at the moment is to make a check on PCLVisualizer::wasStopped(), only for Mac and VTK6.1+, on the status of win_->IsDrawable(), and if that returns false, invoke PCLVisualizer::close().

Are there other methods, which get called regularly, where I can make this check, so that wasClosed() is limited to the returning the stopped_ flag? ExitMainLoopCallback()?

@VictorLamoine
Copy link
Contributor

I'm not familiar with that part of the PCLVisualizer but ExitMainLoopTimerCallback seems to be right place to do this!

@SergioRAgostinho
Copy link
Member Author

A simple test case that triggers the issue.

#include <pcl/visualization/pcl_visualizer.h>

int
main (int argc, char **argv)
{
    pcl::visualization::PCLVisualizer viewer ("Test");

  /* Main Loop */
  while (!viewer.wasStopped ())
  {
    viewer.spinOnce (100);
    boost::this_thread::sleep (boost::posix_time::microseconds (100000));
  }
  return 0;
}

Edit: Gave it a try with viewer.spin()and it doesn't generate errors upon closing. So it appears to be something specific to spinOnce()

@SergioRAgostinho
Copy link
Member Author

Made a couple of test and the only suitable solution which did not output trash on the console was adding the check to spinOnce(), preventing it to request the interactor to render without having a drawable window. Placing a similar check on the ExitMainLoopTimerCallback() and FPSCallback() was not enough to prevent it from printing errors to the console.

void
pcl::visualization::PCLVisualizer::spinOnce (int time, bool force_redraw)
{
  resetStoppedFlag ();
  #if (defined (__APPLE__) && defined (__MACH__) \
    && ( (VTK_MAJOR_VERSION > 6) || ( (VTK_MAJOR_VERSION == 6) && (VTK_MINOR_VERSION >= 1))))         
    if (!win_->IsDrawable ())
    {
      close ();
      return;
    }
  #endif

  if (time <= 0)
    time = 1;

  if (force_redraw)
    interactor_->Render ();

  DO_EVERY (1.0 / interactor_->GetDesiredUpdateRate (),
    exit_main_loop_timer_callback_->right_timer_id = interactor_->CreateRepeatingTimer (time);
    interactor_->Start ();
    interactor_->DestroyTimer (exit_main_loop_timer_callback_->right_timer_id);
  );
}

@VictorLamoine
Copy link
Contributor

I would change (VTK_MAJOR_VERSION > 6) || ( (VTK_MAJOR_VERSION == 6) to
(VTK_MAJOR_VERSION >= 6), apart from that you're good for a pull request!

@SergioRAgostinho
Copy link
Member Author

My target was VTK >= 6.1.

(((VTK_MAJOR_VERSION > 6) || ((VTK_MAJOR_VERSION == 6) && (VTK_MINOR_VERSION >= 1)))

I think this is the only check that respects this condition. Assuming your suggestion was

((VTK_MAJOR_VERSION >= 6) && (VTK_MINOR_VERSION >= 1))

This would not return true on VTK 7.0 (whenever they release it).

I'll submit the PR tonight.

@VictorLamoine
Copy link
Contributor

Oh you're right!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants