Re: [PATCH 1/5] wined3d: Create a proper texture for the software cursor.
-----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.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSihI1AAoJEN0/YqbEcdMwAN4P/iRR8C1ctmY2Eu/FUORAIcmr IFDOyZnxecPmM+0pEOX+W2RVrJmwPlnI8PDBwmKnqJNx80FxEWHIq4gTzS/InhGJ BykTeNTyb7YdHr76V6lZKr8TJTl0CaP8QWEtnl342lGBFaLjXbGbjN5Uf8v3Nv6O 3mBI0hHKvPB2gNtNfnQA2y+xhE/an0s1P0hAP6SE/BcdB9xZORCyBA5Iq1ajTBqz f9lpiIW8+9vApEEGF9wncikgvJR/snGY+JhzcxCPKg5sslDyhVBY3AgfGOR9y9IU xHgF+nN8G99MJKl/+xuvbAmcAKrltH9iR2VYBH0RtJRF0GvT9mVdbASybR6gak55 j39B+X4VpZor+6bZtaV/0+oGShxEqz4mIu6RwPQHCLL7c5IpRM3SnVmu2BQlTEhB j2SJ61P+uQdAEHAjfcl5blVuhbkPwsGA5m0oNRCRopxylbnYNbM00V8P37kkEg7D bMrs/LkP8QWN4lZoj9kZ4eR9TyvjSkSFL+5eKuULtZNlhUKfKrntBzwKfpuNJYxs 9icHe30boy4aHe0xfrVTcN9K6ALIzV4xmUgItWckjpmRTwOwEnen13tTXcKLmJWG 2CXZEz59sa7eEwc1A7NeIjKpf8EUGG34TIUJtcCT326dWRC32khXPzGKVvgqq94a 7G+ZaRaImayepVr0AKdn =ZJqZ -----END PGP SIGNATURE-----
On 18 November 2013 14:12, Stefan Dösinger <stefandoesinger(a)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.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSihlXAAoJEN0/YqbEcdMwk7cP/i0EpkxGAuCgu/7NHVitxWfy wwnJCnATfXvJMpsM8N8vGJmcadVhl/m3R7QrK6pBxnkhRkuV77DcCvGYbjFxgfBk d14jJ5pi32irJAT9OUqoRm7nLC1yY2h38KBZlKXow6o4tRt257Osl981way1hswf r+quKzNtRuQq5qOR/mq8PzkMrcpMmH0Mm/kADCPjPy5fti/VP6/TxOdkGXSjKDm+ uLc7KPxrdIChT5zzRxg3/88PF1sFksoGnvbxqkoKS3iBTcgS865ZDJklmoyIY/zi JURqa1/8WRizPYO57yxiifHWkSAejFli7URhF+9Nfjv/ngN1VKgu1XuNxH91R2Tv vx7KKsvsxiYT0NeNhJw/Yy2U3icbU4McneLVUgSGHn6n70kHo7cZF0XSf6Yp1ozJ PBB9/yAoUVmUJpGAD93qvnNYPfOrLYPlEbv8OL7d3q0ukpjEBM0AlWdW+T0Px0K+ IK01nWxzzMvRjDpUzYmEsOsKPHnpUvGclP4X1/dOoL4u99YKWoeoi3eDXLhT5CFR b0VMTpIuuZeJO4hiALftPBH88u6rdjALoLa0BIkPvLcD4/o2OQ+7JgOFJ7i4tAce EfG669YAUGjzJyTBA+hNxHGpBEasNIMQbFgiRdqyRFtoT6nE/H/21DOornBOwk0O uAbtMBNOtxR/2HM089eW =DydU -----END PGP SIGNATURE-----
On 18 November 2013 14:42, Stefan Dösinger <stefandoesinger(a)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.
participants (2)
-
Henri Verbeet -
Stefan Dösinger