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