On Fri, Nov 16, 2018 at 5:38 PM Paul Gofman gofmanp@gmail.com wrote:
On 11/16/18 18:08, Matteo Bruni wrote:
Signed-off-by: Matteo Bruni mbruni@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:
- 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.
Use a staging texture if texture is not lockable;
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.