Changeset 39602 in vbox for trunk/src/VBox/Additions/WINNT/Graphics/Wine/wined3d/vboxext.h

Timestamp:

Dec 14, 2011 11:12:17 AM (13 years ago)

Author:

vboxsync

Message:

wine/XPDM: 1. Additional swapchain creation fixes 2. De-libwine'ize wined3d 3. Single context per swapchain 4. wine & crOgl current context sync fixes 5. Proper Get/ReleaseDC handling

File:

• trunk/src/VBox/Additions/WINNT/Graphics/Wine/wined3d/vboxext.h (modified) (2 diffs)

trunk/src/VBox/Additions/WINNT/Graphics/Wine/wined3d/vboxext.h

@@ -17 +17 @@
 #define ___VBOXEXT_H__
 
-#include <windows.h>
+#ifdef VBOX_WINE_WITHOUT_LIBWINE
+# include <windows.h>
+#endif
 #include <iprt/cdefs.h>
-
 
 HRESULT VBoxExtCheckInit();
 HRESULT VBoxExtCheckTerm();
-#if 0
+#if defined(VBOX_WINE_WITH_SINGLE_CONTEXT) || defined(VBOX_WINE_WITH_SINGLE_SWAPCHAIN_CONTEXT)
+# ifndef VBOX_WITH_WDDM
 /* Windows destroys HDC created by a given thread when the thread is terminated
  * this leads to a mess-up in Wine & Chromium code in some situations, e.g.
@@ -30 +32 @@
 HDC VBoxExtGetDC(HWND hWnd);
 int VBoxExtReleaseDC(HWND hWnd, HDC hDC);
+# endif
+/* We need to do a VBoxTlsRefRelease for the current thread context on thread exit to avoid memory leaking
+ * Calling VBoxTlsRefRelease may result in a call to context dtor callback, which is supposed to be run under wined3d lock.
+ * We can not acquire a wined3d lock in DllMain since this would result in a lock order violation, which may result in a deadlock.
+ * In other words, wined3d may internally call Win32 API functions which result in a DLL lock acquisition while holding wined3d lock.
+ * So lock order should always be "wined3d lock" -> "dll lock".
+ * To avoid possible deadlocks we make an asynchronous call to a worker thread to make a context release from there. */
+void VBoxExtReleaseContextAsync(struct wined3d_context *context);
 #endif