On 24 February 2014 15:37, Stefan Dösinger stefan@codeweavers.com wrote:
@@ -1976,6 +1976,19 @@ static inline void context_invalidate_active_texture(struct wined3d_context *con context_invalidate_state(context, STATE_SAMPLER(sampler)); }
+struct wined3d_privstore +{
- struct list content;
+};
+struct wined3d_privstore *wined3d_privstore_create(void) DECLSPEC_HIDDEN; +void wined3d_privstore_destroy(struct wined3d_privstore *store) DECLSPEC_HIDDEN; +HRESULT wined3d_privstore_free_private_data(struct wined3d_privstore *store, const GUID *guid); +HRESULT wined3d_privstore_get_private_data(const struct wined3d_privstore *store,
const GUID *guid, void *data, DWORD *data_size, BOOL addref) DECLSPEC_HIDDEN;+HRESULT wined3d_privstore_set_private_data(struct wined3d_privstore *store,
const GUID *guid, const void *data, DWORD data_size, DWORD flags) DECLSPEC_HIDDEN;#define WINED3D_RESOURCE_ACCESS_GPU 0x1 #define WINED3D_RESOURCE_ACCESS_CPU 0x2
I'm not entirely convinced this is how we want this to work. Calling HeapAlloc() for a struct list seems less than ideal, and I'd like the WINED3DSPD_IUNKNOWN handling to be done by the callers.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-02-25 13:27, schrieb Henri Verbeet:
Calling HeapAlloc() for a struct list seems less than ideal,
That is easy to fix. It will move the actual structure definition into the public header though.
and I'd like the WINED3DSPD_IUNKNOWN handling to be done by the callers.
For get_private_data that's fairly easy. I can just return the stored flags and the caller decides if it wants to addref anything.
For set_private_data it's tricky. The caller would have to know the old contents, same for free_private_data and the destruction of the store. With that amount of logic in the caller we might as well re-implement the entire thing in each calling library.
But the getter behavior is version specific part, so I think just moving that out makes sense on its own. wine-devel@winehq.org
-
Henri Verbeet -
Stefan Dösinger