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

[Nikolay Sivov]

On 29.04.2016 12:16, Aaryaman Vasishta wrote:
> On Fri, Apr 29, 2016 at 12:56 PM, Stefan Dösinger
> <stefandoesinger at gmail.com <mailto:stefandoesinger at gmail.com>> wrote:
> 
> 
>     > Am 28.04.2016 um 20:17 schrieb Aaryaman Vasishta <jem456.vasishta at gmail.com <mailto: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 texture->d3drm.

What will happen if you release IDirect3DRM before calling InitFrom*,
and then call InitFrom* expecting already released IDirect3DRM to be valid?

>  
> 
> 
>     >  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.
> 
> Cheers,
> Aaryaman
> 
> 
> 
>