Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.
On Monday 31 October 2011 19:48:12 Henri Verbeet wrote:
--- dlls/ddraw/surface.c | 3 +++ dlls/wined3d/surface.c | 11 +++++++++++ include/wine/wined3d.h | 1 + 3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/dlls/ddraw/surface.c b/dlls/ddraw/surface.c index 3860959..567d086 100644 --- a/dlls/ddraw/surface.c +++ b/dlls/ddraw/surface.c @@ -5273,6 +5273,9 @@ HRESULT ddraw_surface_init(IDirectDrawSurfaceImpl *surface, IDirectDrawImpl *ddr if (desc->ddsCaps.dwCaps & DDSCAPS_ZBUFFER) usage |= WINED3DUSAGE_DEPTHSTENCIL;
+ if (desc->ddsCaps.dwCaps & DDSCAPS_OWNDC) + usage |= WINED3DUSAGE_OWNDC; You would get the same effect by calling GetDC and ReleaseDC from ddraw or ddrawex without another usage flag. Probably ddrawex should do that since it sets DDSCAPS_OWNDC, assuming that IE 8 still uses ddrawex.
+ /* Similar to lockable rendertargets above, creating the DIB section + * during surface initialization prevents the sysmem pointer from changing + * after a wined3d_surface_getdc() call. */ Is this a property of DDSCAPS_OWNDC, or sysmem surfaces in general? I'd expect that this applies to sysmem surfaces in general. Otoh we don't really want to create a DIB section for every sysmem surface, especially with bug 5535 in mind.
On 31 October 2011 20:38, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
You would get the same effect by calling GetDC and ReleaseDC from ddraw or ddrawex without another usage flag. Yes, but I don't think that would be an improvement.
+ /* Similar to lockable rendertargets above, creating the DIB section + * during surface initialization prevents the sysmem pointer from changing + * after a wined3d_surface_getdc() call. */ Is this a property of DDSCAPS_OWNDC, or sysmem surfaces in general? I'd expect that this applies to sysmem surfaces in general. Probably in general. The way GetDC is supposed to work is probably by asking the graphics driver to create a DC on top of the existing memory or texture, instead of the DIB section hacks we do in wined3d. However, without much more invasive changes to the way wined3d interacts with winex11 that's just not going to happen, and since OWNDC implies the application wants to keep the DC around anyway, we might as well set it up at surface initialization.
On Monday 31 October 2011 21:06:09 Henri Verbeet wrote:
Probably in general. The way GetDC is supposed to work is probably by asking the graphics driver to create a DC on top of the existing memory or texture, instead of the DIB section hacks we do in wined3d. In the days of the old ddraw code we used to have a Wine-specific export in gdi32 that did that, but I don't think adding that back 1:1 is a good solution.
We could allocate surface memory in ddraw and copy between that and the memory wined3d's map() returns for some or all surfaces. This would deal with cases where an app(Some Windows Media Player 9 visualization plugins specifically) use SetSurfaceDesc to set lpSurface and then call GetDC, and we could get rid of SFLAG_USERPTR in wined3d. It would also be more reliable for the backbuffer than hoping the memory returned by glMapBuffer remains valid. Alternatively we could make the dibsection a separate location, but that wouldn't deal with apps that want the backbuffer memory to stay the same.
and since OWNDC implies the application wants to keep the DC around anyway, we might as well set it up at surface initialization. This is probably correct, but do you have docs for OWNDC, besides of the name and very short description in msdn/sdk?
I don't think IE8 sets OWNDC here, this is most likely our ddrawex.dll. And the main reason I've set it there is because it kinda-sorta sounds like what the ddrawex DDSCAPS_VIDEOMEMORY | DDSCAPS_SYSTEMMEM hack is doing, not because I had any in-depth information what OWNDC does, so I'd be wary about reading too much into it.
participants (2)
-
Henri Verbeet -
Stefan Dösinger