What does cv::startwindowthread() do?

1

What does cv::startwindowthread()do? When should it be used? Is it called automatically with cv::imshow or cv::waitKey?
The documentation doesn’t provide any hint:
https://docs.opencv.org/4.5.1/d7/dfc/group__highgui.html#ga2c6ecef4f85d8e5cbefec39c9e82ece0

In Qt implementation it seemingly does nothing (at window_QT.cpp#L624)

But in Gtk something happens:

1 Like
2

I think it is opencv legacy. read Unused function startWindowThread ? · Issue #7562 · opencv/opencv · GitHub

3

I wouldn’t call it legacy but “under-utilized” and under-documented.

the point of it is to keep GUI responsive without having to call waitKey all the time.

some backends, gtk apparently, don’t implement it. there you have no choice but to keep calling waitKey.

1 Like
4

It appears to be very important in my context (Ubuntu and indeed gtk): I am putting the visualization commands in a separate thread, and I had some random opencv gui crashes that didn’t go until I inserted a startWindowThread where I was spawning my thread. Also, having that call makes indeed unnecessary, as you suggested, calling waitKey.
So again, not at all a legacy or trivial function.

5

Ok my be it’s not legacy but this function is only for gtk when you use imshow not in the main thread

GTK+, however, is not thread safe. You should only use GTK+ and GDK from the thread gtk_init() and gtk_main() were called on. This is usually referred to as the “main thread”.

In all case don’t use highgui module out of the mainthread.

How can you do that?

1 Like
6

how?

waitKey contains GUI event/message processing. a GUI will not do anything, not move, not show a picture, not redraw, not react to mouse or keyboard, unless those messages are handled.

the spawned thread takes that over, so you don’t have to call waitKey anymore. I would expect the thread to put key events into a separate queue so waitKey can get them. without the thread running, waitKey has to do it all.

I took a peek. cvStartWindowThread is the actual implementation. only the gtk backend implements it. if code uses it, that code will only run properly using the gtk backend, none of the others.

if you need portability, I would recommend to not use startWindowThread and instead make sure that waitKey is called regularly.

I think it’s a neat idea but the current state of its implementation limits its utility.

maybe I’ll look into implementing that thread for the w32 backend. that, or rather a thread per window, might fix some stuttering issue I see with multiple windows in the w32 OpenGL mode too: only the focused one gets all the updates, the rest only redraw sometimes.

1 Like
7

another issue on this function:

tagged with the 5.0 milestone… I wonder if they’ll axe that function and convert it to implicit behavior of namedwindow and imshow calls.

I really think it’d improve usability to have GUI stuff stay responsive without having to be in a waitKey call… at least for some backends.

2 Likes
8

I understand that you want to write a full multiplatform gui inside opencv.
Faster way is to use a multiplatform GUI and opencv as image processing library

1 Like