[PATCH 5/6] wined3d: Don't set SFLAG_DYNLOCK at surface creation.
Stefan Dösinger
stefan at codeweavers.com
Fri Jan 17 06:27:17 CST 2014
We no longer depend on SFLAG_DYNLOCK to create buffers and PIN_SYSMEM
makes sure the address remains constant.
---
dlls/wined3d/surface.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index def47d3..87de9e1 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -6385,16 +6385,6 @@ static HRESULT surface_init(struct wined3d_surface *surface, struct wined3d_text
if (lockable || desc->format == WINED3DFMT_D16_LOCKABLE)
surface->resource.access_flags |= WINED3D_RESOURCE_ACCESS_CPU;
- /* I'm not sure if this qualifies as a hack or as an optimization. It
- * seems reasonable to assume that lockable render targets will get
- * locked, so we might as well set SFLAG_DYNLOCK right at surface
- * creation. However, the other reason we want to do this is that several
- * ddraw applications access surface memory while the surface isn't
- * mapped. The SFLAG_DYNLOCK behaviour of keeping SYSMEM around for
- * future locks prevents these from crashing. */
- if (lockable && (desc->usage & WINED3DUSAGE_RENDERTARGET))
- surface->flags |= SFLAG_DYNLOCK;
-
surface->map_binding = WINED3D_LOCATION_SYSMEM;
/* Call the private setup routine */
--
1.8.3.2
More information about the wine-patches
mailing list