cv::imshow sometimes is very slow

Question

I've got a problem with cv::imshow. It normally consumes about 1-2 ms processing time for my image size but at some point in my processing-pipeline it uses 4-8 ms for the same kind of images.

I have a method

void Tool::displayImage()
{
   startTimeMeasure();
   cv::imshow("output",image);
   evaluateTimeMeasure();
}

image is a member variable and the highgui window is created somewhere else. Time measurement works with boost::posix_time ptime and time_duration.

cvStartWindowThread();

was called.

The point is, that if displayImage() is called within a complex processing chain (loading image from videofile, some preprocessing etc), cv::imshow becomes very slow, while a call in a "paused" video to redraw an updated image is very fast.

If I add a cv::waitKey(10) before the time measurement's beginning, cv::imshow becomes fast, too. So there might be some (gui?) things which have to be processed which block cv::imshow? cv::waitKey(40) is called in a separate thread in loop which waits for keyboard input to control (e.g. pause/resume) the video. As far as I know, cv::imshow is performed in some kind of queue which is processed during cv::waitKey times?!? Where can I find information about all the tasks which are performed during that times? Maybe I can rearrange some parts of my code (really complex by now) to allow faster imshow all the time.

So what happens in a cv::imshow call and what might be the reasons for the slow/fast execution of the same call in different situations?

EDIT: one difference I recognized between regular execution and processing in 'pause' mode is, that in pause mode the method is started from a bound mouse callback function (that's from within the windowThread?) while in regular mode it's started from the main processing thread.

Answer 1

This is a typical problem with OpenGL, and the OpenCV windows can be created using OpenGL. There is a problem with SwapBuffers (see SDL_GL_SwapBuffers() is intermittently slow and others), which is often solved by adding a small sleep before it.

• Disabling vertical synchronization in the video drivers may help.
• Not having too many image windows opened (a typical plague of many OpenCV programs) helps.
• Using a different API than OpenGL to create the windows may help (will likely require recompiling highgui).