-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 2016-07-10 um 21:49 schrieb Aaryaman Vasishta:
I believe the "obj == ctxt->obj" tests in destroy_callback and destroy_callback1 should cover this. See test_destroy_callback.
If I understand it correctly not quite, because you're only ever calling AddDestroyCallback via IDirect3DRMObject, never via IDirect3DRMSomethingElse.
(Re-CCed wine-devel)
On Mon, Jul 11, 2016 at 3:18 AM, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 2016-07-10 um 21:49 schrieb Aaryaman Vasishta:
I believe the "obj == ctxt->obj" tests in destroy_callback and destroy_callback1 should cover this. See test_destroy_callback.
If I understand it correctly not quite, because you're only ever calling AddDestroyCallback via IDirect3DRMObject, never via IDirect3DRMSomethingElse.
(Re-CCed wine-devel)
My bad, I may have clicked on "Reply" instead of "Reply to All" on gmail again..
Anyways, the vtable qi tests tests written so far show that querying IDirect3DRMObject from a particular interface will return version 1 of that interface. So technically it all comes down to calling IDirect3DRM<Interface_name>::AddDestroyCallback(&object->version1_vtable, ...);. In our implementation of this method (see d3drm_main.c), we have passed version 1 of the relevant interface while calling the destroy callbacks within d3drm_object_destroy. The tests seem to agree with that implementation so far.
Do correct me if I have misunderstood something here, though.
Cheers, Aaryaman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 2016-07-10 um 23:14 schrieb Aaryaman Vasishta:
Anyways, the vtable qi tests tests written so far show that querying IDirect3DRMObject from a particular interface will return version 1 of that interface. So technically it all comes down to calling IDirect3DRM<Interface_name>::AddDestroyCallback(&object->version1_vtable, ...);. In our implementation of this method (see d3drm_main.c), we have passed version 1 of the relevant interface while calling the destroy callbacks within d3drm_object_destroy. The tests seem to agree with that implementation so far.
Well, but you can call AddDestroyCallback on the version 3 interface too:
IDirect3DRMDevice *dev1; IDirect3DRMDevice3 *dev3;
dev1 = create_device(); dev3 = dev1->qi(IID_IDirect3DRMDevice3);
dev1->AddDestroyCallback(...); dev3->AddDestroyCallback(...);
The current code will always pass dev1 to the callback. It may be correct, it may be wrong.
But yeah, we won't accidentally pass an IDirect3DRMFrame interface to the callback if AddDestroyCallback was called on a device.
On Mon, Jul 11, 2016 at 12:05 PM, Stefan Dösinger <stefandoesinger@gmail.com
wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 2016-07-10 um 23:14 schrieb Aaryaman Vasishta:
Anyways, the vtable qi tests tests written so far show that querying IDirect3DRMObject from a particular interface will return version 1 of that interface. So technically it all comes down to calling IDirect3DRM<Interface_name>::AddDestroyCallback(&object->version1_vtable, ...);. In our implementation of this method (see d3drm_main.c), we have passed version 1 of the relevant interface while calling the destroy callbacks within d3drm_object_destroy. The tests seem to agree with that implementation so far.
Well, but you can call AddDestroyCallback on the version 3 interface too:
IDirect3DRMDevice *dev1; IDirect3DRMDevice3 *dev3;
dev1 = create_device(); dev3 = dev1->qi(IID_IDirect3DRMDevice3);
dev1->AddDestroyCallback(...); dev3->AddDestroyCallback(...);
The current code will always pass dev1 to the callback. It may be correct, it may be wrong.
This is where the obj == ctxt->obj test comes in. obj is the interface
passed to the callback, and ctxt->obj is the one we pass into the context, which is our interface QI'd to IDirect3DRMObject. Now if we consider this test + the vtable QI tests, we can (in)directly prove that the interface passed to the destroy callback is always the version 1 of that interface. The tests would have failed on wine if e.g. I passed version 2 or 3 interface into the destroy callback. I agree that there are no direct tests confirming this though, but hopefully the two tests combined should be enough to confirm this.
Cheers, Aaryaman
-
Aaryaman Vasishta -
Stefan Dösinger