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.

Aril

Any chance you found an explanation? – Bermejo

nope... but didnt (have to) follow that any further... – Aril

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).

Perplexity

wrong answer. opengl is only used for 3d content, not for 2d image blitting – Scissure

@Scissure are you sure? I'm looking at void cv::imshow( const string& winname, InputArray _img ) in window.cpp right now, and it sure as hell calls setOpenGlDrawCallback(winname, glDrawTextureCallback, &tex); (OpenCV 2.4.7). Please, do not downvote the post unless you are sure. – Perplexity

How exactly does that "3D content" look? This will just draw a textured quad / use glDrawPixels! – Perplexity

blitting an image on e.g. win will take you here - so that's plain GDI used. – Scissure

That is somehow inside an #if 0 block. Totally gets called. My OpenCV has a lot of #ifdef HAVE_OPENGL in there, try this, that finally ends here. – Perplexity

Also, the question is related to performance. If OpenGL was used (that is speculative on my part), there are some pretty similar patterns to what Micka is asking. Might be worth to someone. – Perplexity

so, sorry, you're right, i'm wrong. (had to edit it to revoke the dv) – Scissure

Sure, no problem. Happens to me all the time. – Perplexity

should we remove the comments ? – Scissure

Nah, might be useful to someone following the same chain of thought. – Perplexity

sorry to interrupt but how would you go about using a different API and disabling vertical sync in the video drivers? also, my program (One Window) is not simply slow but hangs altogether, could that still be the same mistake? – Creamery

@Creamery a different API is selected somewhere in OpenCV configuration, using a macro. Disabling vsync in video drivers for nvidia and windows - start nvidia control panel, go to "manage 3D settings" and in the list select vertical sync = off. Unlikely the same issue, more likely the image you are trying to display is damaged. – Perplexity