[PATCH 2/3] d3drm/tests: Add test for IDirect3DRM*::CreateDeviceFromSurface (try 6).

[Aaryaman Vasishta]

I was corrected by Henri about that behaviour. I shouldn't use that as a
check.
Regardless, the tests do by themselves amount to the fact that the depth
surface remains attached even after we explictly release all our references
to it (therefore the refcount is 1 after calling release on the last
reference). So after destroying the root surface, the attached surface is
also destroyed as it's refcount was 1, and ddraw implicitly calls
DeleteAttachedSurface which decrements that refcount to 0, in turn
destroying it.

On Fri, Jun 26, 2015 at 6:26 PM, Aaryaman Vasishta <
jem456.vasishta at gmail.com> wrote:

> About the refcount of the depth surface after render target is destroyed:
> How about a simple NULL check for lpvtbl?
>
> On Fri, Jun 26, 2015 at 5:32 PM, Aaryaman Vasishta <
> jem456.vasishta at gmail.com> wrote:
>
>>
>>
>> On Fri, Jun 26, 2015 at 2:32 AM, Stefan Dösinger <
>> stefandoesinger at gmail.com> wrote:
>>
>>> Minor issue: I don't think there's a reason to destroy and recreate the
>>> surface.
>>>
>> The other way afaik is to QI surface version >= 3 and then call
>> SetSurfaceDesc. This seemed easier to do so. Is there some other way?
>>
>> > +    IDirectDrawSurface_Release(d3drm_ds);
>>> > +    IDirectDrawSurface_Release(d3drm_surface);
>>> > +    IDirectDrawSurface_Release(ds);
>>> What happens to the depth buffer here? Does it remain attached?
>>>
>>
>> At this point (after releasing ds) the refcounts of both ds and render
>> target (i.e. surface) become 1.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150626/bd90ecdc/attachment-0001.html>