[PATCH 2/2] d3dx9: Add FIXME for unlockable source surface in D3DXLoadSurfaceFromSurface().

[Matteo Bruni]

On Fri, Nov 16, 2018 at 5:38 PM Paul Gofman <gofmanp at gmail.com> wrote:
>
> On 11/16/18 18:08, Matteo Bruni wrote:
> > Signed-off-by: Matteo Bruni <mbruni at codeweavers.com>
> > ---
> > Do you want to take a shot at implementing the missing functionality?
> > I imagine it's just a matter of creating a temporary D3DPOOL_SYSTEMMEM
> > surface, filling it with the contents of the render target with
> > GetRenderTargetData() and locking that surface instead, if the
> > original source surface is a render target.
> >
> >
> Yes, I could, but I thought it must be a bit more complicated than that.
> We probably want to use d3d9 device StretchBlt or UpdateTexture when
> possible (no colorkey and other restrictions pass) for performance
> reasons. If we can't use that and can't lock source rectangle should we
> assume that it is necessarily render target and use
> GetRenderTargetData(), or rather use StretchRect()/UpdateTexture() with
> staging texture's surface?

I was thinking of just calling GetDesc() on the source surface and
checking for D3DUSAGE_RENDERTARGET.
I'm not sure that using StretchRect() / UpdateSurface() is that useful
in practice, e.g. the default filter would disqualify both of them
immediately. Also StretchRect() has pretty weird / inconsistent
restrictions on its use. That said, if you want to add a fast path for
the cases that are supported by those I certainly won't oppose it :)

>      We also need to care about possibly unlockable destination surface.
> It concerns some other D3DX surface manipulating functions which I did
> not test yet for ability to workaround this case. So I would suggest the
> following steps:
>
> 1. Add a code path for StrecthBlt (which would be a priority over
> locking the texture). I guess this should cover the majority of
> practical cases.
>
> 2. Use a staging texture if texture is not lockable;
>
> 3. Fix output to unlockable texture through staging texture (with some
> tests for the other functions touching this).

Sounds good. I'd probably wait for Henri's patches before venturing
too far along the plan.