[PATCH 4/4] d3drm: Implement IDirect3DRMDevice*::Add/DeleteDestroyCallback. (v2)

[Aaryaman Vasishta]

On Mon, Jul 11, 2016 at 1:11 PM, Aaryaman Vasishta <
jem456.vasishta at gmail.com> wrote:

> CC'ing to wine-devel again.
>
> On Mon, Jul 11, 2016 at 1:10 PM, Aaryaman Vasishta <
> jem456.vasishta at gmail.com> wrote:
>
>>
>>
>> On Mon, Jul 11, 2016 at 1:06 PM, Aaryaman Vasishta <
>> jem456.vasishta at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Jul 11, 2016 at 12:05 PM, Stefan Dösinger <
>>> stefandoesinger at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160711/a16ec77a/attachment.html>