Unused function startWindowThread ?

[LaurentBerger]

Hi,
reading doc i found startThread It seems this function is empty or used as an internal function :
https://github.com/opencv/opencv/blob/master/modules/highgui/src/window.cpp#L239
and https://github.com/opencv/opencv/blob/master/modules/highgui/src/window.cpp#L642
May be it shouldn't be in doc

[kinchungwong]

The function on Line 642 that gives an error at runtime is only enabled if OpenCV is built without linking to any of the supported windowing system API.
See

opencv/modules/highgui/src/window.cpp

Lines 509 to 516 in 9b2b840

	#if defined (HAVE_WIN32UI) // see window_w32.cpp
	#elif defined (HAVE_GTK) // see window_gtk.cpp
	#elif defined (HAVE_COCOA) // see window_carbon.cpp
	#elif defined (HAVE_CARBON)
	#elif defined (HAVE_QT) // see window_QT.cpp
	#elif defined (WINRT) && !defined (WINRT_8_0) // see window_winrt.cpp
	#else

The comments on these lines explained where to find the corresponding function implementations for each windowing API.

#if   defined (HAVE_WIN32UI)  // see window_w32.cpp
#elif defined (HAVE_GTK)      // see window_gtk.cpp
#elif defined (HAVE_COCOA)    // see window_carbon.cpp
#elif defined (HAVE_CARBON)
#elif defined (HAVE_QT)       // see window_QT.cpp
#elif defined (WINRT) && !defined (WINRT_8_0) // see window_winrt.cpp

Currently, it appears that only GTK requires this function. For other windowing API, the function is empty. Search results: https://github.com/opencv/opencv/search?utf8=%E2%9C%93&q=cvStartWindowThread

[mshabunin]

This function is exported, we can not remove it from public API without breaking compatibility. Probably we could deprecate it and remove from API and documentation in future.

[caraffi]

I think the fact that remains in the API but it is not document is very confusing. In the case of GTK, is it necessary to call it or is it automatically called?

[crackwitz]

related issue #9087, related forum thread https://forum.opencv.org/t/what-does-cv-startwindowthread-do/1326

5.0 milestone... if I am informed correctly, a unified OpenGL GUI is planned for that. regardless of whether this function is removed, I'd still like to see the behavior of GUI staying responsive in the absence of waitKey calls. highly convenient, particularly when prototyping interactively with python, or single-stepping through code. I don't know how the new OpenGL GUI is going to be implemented but if it involves an event loop thread, perhaps spawn it implicit in the first namedWindow/imshow call.