=?UTF-8?Q?Stefan=20D=C3=B6singer=20?=: wined3d: Don' t set SFLAG_DYNLOCK at surface creation.

Alexandre Julliard julliard at winehq.org
Fri Jan 17 11:55:33 CST 2014


Module: wine
Branch: master
Commit: 5630cb5dc8ef7e9a8195262726f73d6828f59a6c
URL:    http://source.winehq.org/git/wine.git/?a=commit;h=5630cb5dc8ef7e9a8195262726f73d6828f59a6c

Author: Stefan Dösinger <stefan at codeweavers.com>
Date:   Fri Jan 17 13:27:17 2014 +0100

wined3d: Don't set SFLAG_DYNLOCK at surface creation.

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 */




More information about the wine-cvs mailing list