<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 9:13 PM, Henri Verbeet <span dir="ltr"><<a href="mailto:hverbeet@gmail.com" target="_blank">hverbeet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 11 May 2016 at 16:43, Aaryaman Vasishta <<a href="mailto:jem456.vasishta@gmail.com" target="_blank">jem456.vasishta@gmail.com</a>> wrote:<br>
> @@ -46,10 +46,27 @@ static inline struct d3drm_texture *impl_from_IDirect3DRMTexture3(IDirect3DRMTex<br>
><br>
>  void d3drm_texture_destroy(struct d3drm_texture *texture)<br>
>  {<br>
> +    if (texture->image)<br>
> +        IDirect3DRM_Release(texture->d3drm);<br>
>      d3drm_object_cleanup((IDirect3DRMObject*)&texture->IDirect3DRMTexture3_iface, &texture->obj);<br>
</span>It's somewhat hypothetical, but it seems safer to release the<br>
IDirect3DRM interface after the d3drm_object_cleanup() call, in case<br>
there are callbacks that (implicitly) depend on the Direct3DRM object<br>
still existing. (E.g., is it possible to call<br>
IDirect3DRMObject2::GetDirect3DRM() on textures?)<br></blockquote><div>Right, it makes sense once you take in future pathces in mind.<br></div><div>A quick test reveals that you it's possible to call IDirect3DRMObject2::GetDirect3DRM() on textures (and probably any object that inherits IDirect3DRMObject2) so this change does make sense for when this interface is implemented.<br></div><div> </div><br></div><div class="gmail_quote">I'll resent this patch as well.<br><br><br></div><div class="gmail_quote">Cheers,<br></div><div class="gmail_quote">Aaryaman<br></div><br></div></div>