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?
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).