[PATCH 2/4] d3drm: Implement IDirect3DRMTexture{2-3}_InitFromImage.

Aaryaman Vasishta jem456.vasishta at gmail.com
Fri Apr 29 04:16:04 CDT 2016

On Fri, Apr 29, 2016 at 12:56 PM, Stefan Dösinger <stefandoesinger at gmail.com
> wrote:

> > Am 28.04.2016 um 20:17 schrieb Aaryaman Vasishta <
> jem456.vasishta at gmail.com>:
> >
> > +    if (texture->d3drm && texture->initialized)
> > +        IDirect3DRM_Release(texture->d3drm);
> I thought the idea was to use AddDestroyCallback instead of a flag to
> control the Release call. Do I remember this incorrectly, or what's the
> reason for going back to a flag?
> Also, what's the difference between image != NULL and initialized? Or, in
> a later stage when you have initFromTexture or what it is called, image !=
> NULL || ddraw_texture != NULL?
AddDestroyCallback would be used to destroy the image struct, which will be
used when InitFromFile will be implemented. Since the image here is
provided by the application, there wasn't any need to use a destroy
callback right now.

texture->initialized is only used to indicate whether InitFrom* was called
on texture or not. As you can see from the tests, d3drm AddRef's
IDirect3DRM only after InitFrom* is called. (I had initially thought that
CreateObject would do that, but the tests say otherwise).

Since we needed the reference to IDirect3DRM when AddRefing it during the
InitFrom* calls, I decided to initialize texture->d3drm at CreateObject
without AddRefing it there. So if someone decides to release a texture
created using CreateObject but not initialized using InitFrom*, the
texture->initialized member will prevent d3drm from releasing

> >  IDirect3DRM_AddRef(texture->d3drm);
> > +
> > +    if (texture->image)
> > +        return D3DRMERR_BADOBJECT;
> Afair  the ref leak here is intentional. If it is, I think it's worth
> adding a comment.
Right, I will add comments above the related test as well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20160429/fbec0057/attachment.html>

More information about the wine-devel mailing list