[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 6/7] d3drm: Implement IDirect3DRMViewport*::Init. (v3)
From:       Aaryaman Vasishta <jem456.vasishta () gmail ! com>
Date:       2016-06-30 11:40:54
Message-ID: CABVHfRuD=LkKtTLuGfWmNxgkMjAz4kHrbP5jFeO64VpcyS5KdA () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


On Tue, Jun 28, 2016 at 3:24 AM, Aaryaman Vasishta <
jem456.vasishta@gmail.com> wrote:


>
> +    if (viewport->d3d_viewport)
> +        return D3DRMERR_BADOBJECT;
> +
> +    IDirect3DRM_AddRef(viewport->d3drm);
> +
>
FWIW, I didn't put the intentional d3drm, camera leaks here because it
seems that the device controls the leaked references via some sort of
destroy callback on the device. (See the todo_wine tests in this patch).

> +    todo_wine ok(ref4 > frame_ref2, "Expected ref4 > frame_ref2, got
> frame_ref2 = %u, ref4 = %u.\n", frame_ref2, ref4);
> +
> +    IDirect3DRMDevice3_Release(device3);
> +    IDirect3DRMDevice_Release(device1);
>
I tried to release d3drm explicitly myself, like how I did with the texture
tests. But the tests would then crash here, at IDirect3DRMDevice_Release,
where the device gets destroyed. Which probably indicates that the device
stores a list of leaked references and releases them on getting destroyed.
For now I've decided to avoid the leak, thus avoiding the use of a destroy
callback, and implementing this as a separate later on if an application
demands it, unless it's safer to get this done on priority.

Cheers,
Aaryaman

[Attachment #5 (text/html)]

<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun \
28, 2016 at 3:24 AM, Aaryaman Vasishta <span dir="ltr">&lt;<a \
href="mailto:jem456.vasishta@gmail.com" \
target="_blank">jem456.vasishta@gmail.com</a>&gt;</span> wrote:<br><div>  \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
+      if (viewport-&gt;d3d_viewport)<br>
+            return D3DRMERR_BADOBJECT;<br>
+<br>
+      IDirect3DRM_AddRef(viewport-&gt;d3drm);<br>
+<br></blockquote><div><div>FWIW, I didn&#39;t put the intentional d3drm, camera \
leaks here because  it seems that the device controls the leaked references via some \
sort  of destroy callback on the device. (See the todo_wine tests in this 
patch).<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex" class="gmail_quote">+      todo_wine ok(ref4 &gt; \
frame_ref2, &quot;Expected ref4 &gt; frame_ref2, got frame_ref2 = %u, ref4 = \
%u.\n&quot;, frame_ref2, ref4);<br> +<br>
+      IDirect3DRMDevice3_Release(device3);<br>
+      IDirect3DRMDevice_Release(device1);<br></blockquote></div><div>I tried to \
release d3drm explicitly myself, like  how I did with the texture tests. But the \
tests would then crash here, at IDirect3DRMDevice_Release, where the device gets \
destroyed. Which probably indicates that the device  stores a list of leaked \
references and releases them on getting  destroyed. For now I&#39;ve decided to avoid \
the leak, thus avoiding the use of a destroy callback, and implementing this as a \
separate later on if an application demands it, unless it&#39;s safer to get this \
done on priority.<br><br></div><div>Cheers,<br></div>Aaryaman \
<br></div></div></div></div>


[Attachment #6 (text/plain)]




[prev in list] [next in list] [prev in thread] [next in thread]