<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"><<a href="mailto:jem456.vasishta@gmail.com" target="_blank">jem456.vasishta@gmail.com</a>></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->d3d_viewport)<br>
+        return D3DRMERR_BADOBJECT;<br>
+<br>
+    IDirect3DRM_AddRef(viewport->d3drm);<br>
+<br></blockquote><div><div>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).<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 > frame_ref2, "Expected ref4 > frame_ref2, got frame_ref2 = %u, ref4 = %u.\n", 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'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.<br><br></div><div>Cheers,<br></div>Aaryaman <br></div></div></div></div>