2009/6/14 Stefan Dösinger stefan@codeweavers.com:
+static void surface_allocate_surface(IWineD3DSurfaceImpl *This, GLenum internal, GLsizei width, GLsizei height, GLenum format, GLenum type,
DWORD client_store_flag) {
I think that's ugly.
More importantly, I don't see how client storage can be enabled for one texture but not the other.
Am Montag, 15. Juni 2009 09:16:07 schrieb Henri Verbeet:
2009/6/14 Stefan Dösinger stefan@codeweavers.com:
+static void surface_allocate_surface(IWineD3DSurfaceImpl *This, GLenum internal, GLsizei width, GLsizei height, GLenum format, GLenum type, + DWORD client_store_flag) {
I think that's ugly.
Suggestions?
More importantly, I don't see how client storage can be enabled for one texture but not the other.
In the current code, we don't do that, because only via ddraw.dll the use of client storage can change, and only d3d9 can use sRGB textures. What made me write this patch was the hack that disables client storage on sRGB textures(causes a crash on Leopard, fixed in Snow Leopard), but there are other situations which are tricky with one client storage flag, like unsetting the flag when the texture is deleted. I also don't want to rely on the exclusiveness of sRGB and client storage switching factors.
2009/6/15 Stefan Dösinger stefan@codeweavers.com:
In the current code, we don't do that, because only via ddraw.dll the use of client storage can change, and only d3d9 can use sRGB textures.
No, SFLAG_CLIENT only depends on the availability of the extension, and other surface flags. Since neither of those will be different between the RGB and sRGB textures of a given surface, neither will SFLAG_CLIENT.
What made me write this patch was the hack that disables client storage on sRGB textures(causes a crash on Leopard, fixed in Snow Leopard), but there are other situations which are tricky with one client storage flag, like unsetting the flag when the texture is deleted. I also don't want to rely on the exclusiveness of sRGB and client storage switching factors.
Unsetting the flag when the texture is deleted is redundant, if there's no texture in the first place it obviously won't be using client storage either.
Am Montag, 15. Juni 2009 16:19:22 schrieb Henri Verbeet:
2009/6/15 Stefan Dösinger stefan@codeweavers.com:
In the current code, we don't do that, because only via ddraw.dll the use of client storage can change, and only d3d9 can use sRGB textures.
No, SFLAG_CLIENT only depends on the availability of the extension, and other surface flags. Since neither of those will be different between the RGB and sRGB textures of a given surface, neither will SFLAG_CLIENT.
It does also depend on texture conversion. If we're using a converted texture, the texture data is different from resource.allocatedMemory, in which case we disable client storage.
2009/6/15 Stefan Dösinger stefan@codeweavers.com:
Am Montag, 15. Juni 2009 16:19:22 schrieb Henri Verbeet:
2009/6/15 Stefan Dösinger stefan@codeweavers.com:
In the current code, we don't do that, because only via ddraw.dll the use of client storage can change, and only d3d9 can use sRGB textures.
No, SFLAG_CLIENT only depends on the availability of the extension, and other surface flags. Since neither of those will be different between the RGB and sRGB textures of a given surface, neither will SFLAG_CLIENT.
It does also depend on texture conversion. If we're using a converted texture, the texture data is different from resource.allocatedMemory, in which case we disable client storage.
Sure, but unless you split up SFLAG_CONVERTED first, that flag is also the same for RGB and sRGB.
Am Montag, 15. Juni 2009 22:20:33 schrieb Henri Verbeet:
Sure, but unless you split up SFLAG_CONVERTED first, that flag is also the same for RGB and sRGB.
You've got a point here, I'll put the patch into my hack collection for now until I find something better. Probably we should put the per GL texture stuff into a dedicated structure and have an array of them in the D3D surface. Kinda like we have the compiled shaders in a d3d shader
-
Henri Verbeet -
Stefan Dösinger