2707f05c46
This reverts commit 8d520b970d3552417005f6dab4f0892485cd14ce. This can actually cause a hard lock due to the windows API when destroying window capture. When the graphics thread locks the source list for doing tick or render, and then the UI thread tries to destroy a source, the UI thread will wait for the graphics thread to complete rendering/ticking of sources. The video_tick of window capture would then check windows in the same process and try to query the window's name via GetWindowText. However, GetWindowText is synchronous, and will not return until the window event has been processed by the UI thread, so it will perpetually lock because the two threads are waiting for each other to finish.
30 lines
592 B
C
30 lines
592 B
C
#pragma once
|
|
|
|
#include <util/dstr.h>
|
|
|
|
enum window_priority {
|
|
WINDOW_PRIORITY_CLASS,
|
|
WINDOW_PRIORITY_TITLE,
|
|
WINDOW_PRIORITY_EXE,
|
|
};
|
|
|
|
enum window_search_mode {
|
|
INCLUDE_MINIMIZED,
|
|
EXCLUDE_MINIMIZED
|
|
};
|
|
|
|
extern bool get_window_exe(struct dstr *name, HWND window);
|
|
|
|
extern void fill_window_list(obs_property_t *p, enum window_search_mode mode);
|
|
|
|
extern void build_window_strings(const char *str,
|
|
char **class,
|
|
char **title,
|
|
char **exe);
|
|
|
|
extern HWND find_window(enum window_search_mode mode,
|
|
enum window_priority priority,
|
|
const char *class,
|
|
const char *title,
|
|
const char *exe);
|