c++, the scope of play Window, cv::namedWindow() and cv::imshow()

asked 2018-11-09 20:08:37 -0600

opencvddddd gravatar image

updated 2018-11-10 05:46:24 -0600

What is the scope of created Window? For example:

void play_function(){
    cv::imshow("display", image data);
}

int main(){
    cv::namedWindow("display", 1)
    for(int i=0; i<10; i++){
        play_function()
    }
}

Since the window "display" in play_function() is not in the scope of initialized "display" in main() as normal scope scheme of general variables, I am not sure the Window "display" are the same one as in main()?

The reason I ask this is that I found out that the first time when calling cv::imshow in play_function, it takes tremendous time, so I am wondering if Window "display" did the initialization again in play_function(). Thanks a lot.

edit retag flag offensive close merge delete

Comments

Post your whole code. What happens if you don't call namedWindow?

sjhalayka gravatar imagesjhalayka ( 2018-11-09 20:41:27 -0600 )edit

You must use waitKey to show image. Now imshow use a list of window name. You should'nt use imshow in another thread

LBerger gravatar imageLBerger ( 2018-11-10 03:13:19 -0600 )edit

as said before, the code you show is somewhat useless, and no, window initialization should not take any significant time. (i also don't see any attempt at profiling anything)

also, there is no "scope" here. those functions are all "global".

berak gravatar imageberak ( 2018-11-10 04:29:07 -0600 )edit

Hi LBerger, you mentioned multi-thread here, the code in my post is simplified version. I did use multi-thread in my code, I initialized in one thread by using cv::namedWindow("display", 1), then I called imshow in another thread by using cv::imshow("display", image data). So I did use namedWindow and imshow in two different threads, so you think it doesn't work? If so, any solution for it? Because I do need to put them in two threads.

opencvddddd gravatar imageopencvddddd ( 2018-11-12 12:32:36 -0600 )edit

@opencvddddd -- naive multithreading is the fastest way to shoot your own foot.

and all gui functions, like imshow(), waitKey() MUST stay on the main thread.

berak gravatar imageberak ( 2018-11-12 12:39:49 -0600 )edit

@berak, thanks a lot for your comment, I am a little confused here, since window "display" created by cv::namedWindow("display", 1) is global, why can I access from another thread? Currently my imshow is in a callback function called by another sub thread, it's not so easy to migrate to main thread, so I am thinking how to make window "display" global.

opencvddddd gravatar imageopencvddddd ( 2018-11-12 19:32:38 -0600 )edit
2

window name are defined in hg_windows. it's a static variable and there is no mutex to manage variable access. In multithread application it means you can get race condition problem

LBerger gravatar imageLBerger ( 2018-11-13 02:35:39 -0600 )edit

In my case, there won't be race condition. It is initialized in main thread with cv::namedWindow("display", 1), the running of another thread including cv::imshow("display", image data) is after the initialization.

opencvddddd gravatar imageopencvddddd ( 2018-11-13 02:48:36 -0600 )edit

@LBerger, is race condition problem the reason I can't use multithread, in my case, there won't be 2 threads accessing window "display" at the same, after initialization in main thread, main thread won't access window "display" any more.

opencvddddd gravatar imageopencvddddd ( 2018-11-13 13:02:37 -0600 )edit

@opencvddddd try to redesign it, so it's using a single thread first. then profile your efforts.

as long as you're trying to cure your (programming logic) design hell with multithreading -- it'll just die.

berak gravatar imageberak ( 2018-11-13 13:07:22 -0600 )edit