CC'ing to wine-devel again.
On Mon, Jul 11, 2016 at 1:10 PM, Aaryaman Vasishta < jem456.vasishta@gmail.com> wrote:
On Mon, Jul 11, 2016 at 1:06 PM, Aaryaman Vasishta < jem456.vasishta@gmail.com> wrote:
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.
Also, I may have written the example incorrectly. You're right about the
fact that calling device3->AddDestroyCallback will pass device3 into this function. But internally this interface will be QI'd to IDirect3DRMObject, and then passed as the first parameter to the destroy callback itself.
On Mon, Jul 11, 2016 at 1:11 PM, Aaryaman Vasishta < jem456.vasishta@gmail.com> wrote:
CC'ing to wine-devel again.
On Mon, Jul 11, 2016 at 1:10 PM, Aaryaman Vasishta < jem456.vasishta@gmail.com> wrote:
On Mon, Jul 11, 2016 at 1:06 PM, Aaryaman Vasishta < jem456.vasishta@gmail.com> wrote:
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.
Also, I may have written the example incorrectly. You're right about the
fact that calling device3->AddDestroyCallback will pass device3 into this function. But internally this interface will be QI'd to IDirect3DRMObject, and then passed as the first parameter to the destroy callback itself.
Umm, It's still not clear whether the interface is QI'd to
IDirect3DRMObject or referenced directly. Our implementation doesn't do the AddRef, but I don't think refcounting matters much in this case, since the callbacks happen right before the object gets destroyed.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 2016-07-11 um 08:46 schrieb Aaryaman Vasishta:
Umm, It's still not clear whether the interface is QI'd to IDirect3DRMObject or referenced directly. Our implementation doesn't do the AddRef, but I don't think refcounting matters much in this case, since the callbacks happen right before the object gets destroyed.
For the mailing list archives: We talked about this on IRC, and it turns out that native always passes the version 1 interface to the callback, regardless of which version was used to call AddDestroyCallback. (or rather, it passes the IDirect3DRMObject interface, which happens to share the vtable with the version 1 interface in all objects as far as we know.
Our code already implements this behavior.
-
Aaryaman Vasishta -
Stefan Dösinger