-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-11-18 10:46, schrieb Henri Verbeet:
- desc.pool = WINED3D_POOL_SYSTEM_MEM;
Why did you use this pool instead of managed or dynamic default to allow a GL blit? I haven't tested this, but I suspect the WINEDDBLT_KEYSRC hack won't work in a software blit.
On 18 November 2013 14:12, Stefan Dösinger stefandoesinger@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-11-18 10:46, schrieb Henri Verbeet:
- desc.pool = WINED3D_POOL_SYSTEM_MEM;
Why did you use this pool instead of managed or dynamic default to allow a GL blit? I haven't tested this, but I suspect the WINEDDBLT_KEYSRC hack won't work in a software blit.
Mostly because the existing code used WINED3D_POOL_SCRATCH. It's also what we use for the logo texture, although arguably that could be changed as well. WINED3D_POOL_DEFAULT could work, but it would require some extra code to destroy the texture on resets.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-11-18 14:22, schrieb Henri Verbeet:
Mostly because the existing code used WINED3D_POOL_SCRATCH.
I think this code predates any pool checks in blits, and I believe I used it because EVE Online passed a WINED3D_POOL_SCRATCH surface to SetCursorProperties and I just copied this behavior.
It's also what we use for the logo texture, although arguably that could be changed as well. WINED3D_POOL_DEFAULT could work, but it would require some extra code to destroy the texture on resets.
I think D3DPOOL_MANAGED should just work.
The reason for the surface on the stack added in 65e5ed60 were cyclic references between surface and device. I think your patch should be safe in this regard, but I cannot remember why I thought this approach wouldn't work back in 2006. Did you consider reference cycles when you wrote your patch? (The logo surface would be affected by the same problem.)
On 18 November 2013 14:42, Stefan Dösinger stefandoesinger@gmail.com wrote:
Am 2013-11-18 14:22, schrieb Henri Verbeet:
Mostly because the existing code used WINED3D_POOL_SCRATCH.
I think this code predates any pool checks in blits, and I believe I used it because EVE Online passed a WINED3D_POOL_SCRATCH surface to SetCursorProperties and I just copied this behavior.
I suppose scratch resources would end up in surface_blt_to_drawable() through surface_blt_special(), as opposed to sysmem resources that would end up using a CPU blit.
It's also what we use for the logo texture, although arguably that could be changed as well. WINED3D_POOL_DEFAULT could work, but it would require some extra code to destroy the texture on resets.
I think D3DPOOL_MANAGED should just work.
Probably, yes.
The reason for the surface on the stack added in 65e5ed60 were cyclic references between surface and device. I think your patch should be safe in this regard, but I cannot remember why I thought this approach wouldn't work back in 2006. Did you consider reference cycles when you wrote your patch? (The logo surface would be affected by the same problem.)
In general this kind of thing is safe because e.g. d3d9 calls wined3d_device_uninit_3d() on release of the d3d9 device. My guess would be that the main reason this didn't work in 2006 was that it was much more painful to create a surface / texture from inside wined3d back then.
-
Henri Verbeet -
Stefan Dösinger