问题
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.
回答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
).
来源:https://stackoverflow.com/questions/19837796/cvimshow-sometimes-is-very-slow