October 2011 - Wine-Devel - list.winehq.org

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.

by Stefan Dösinger

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.

Oct. 31, 2011

Re: [4/4] wined3d: YUY2 and UYVY are block based

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=15193 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 31, 2011

Re: [3/4] d3d9/tests: Test partial block locks

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=15192 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Oct. 31, 2011

Re: ddraw/tests: Move some surface attachment tests from refcount to dsurface and enhance them.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=15183 Your paranoid android. === W2KPROSP4 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === WXPPROSP3 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W2K3R2SESP2 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === WVISTAADM (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W2K8SE (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PRO (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PROX64 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === TEST64_W7SP1 (32 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === W7PROX64 (64 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a === TEST64_W7SP1 (64 bit dsurface) === dsurface.c:1470: Test failed: AddAttachedSurface returned 8876000a

Oct. 31, 2011

Re: [3/4] d3d9/tests: Test partial block locks

by Henri Verbeet

On 31 October 2011 20:03, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + case D3DPOOL_SCRATCH: > + case D3DPOOL_SYSTEMMEM: > + hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 128, 128, formats[i].fmt, > + D3DPOOL_SCRATCH, &surface, 0); That doesn't really test D3DPOOL_SYSTEMMEM.

Oct. 31, 2011

Re: [4/4] wined3d: YUY2 and UYVY are block based

by Henri Verbeet

On 31 October 2011 20:17, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > {WINED3DFMT_ATI2N, GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI, GL_COMPRESSED_LUMINANCE_ALPHA_3DC_ATI, 0, > GL_LUMINANCE_ALPHA, GL_UNSIGNED_BYTE, 0, > - WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING, > + WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING | WINED3DFMT_FLAG_FILTERING | WINED3DFMT_FLAG_COMPRESSED, > GL_COMPRESSED_RED_GREEN_RGTC2 is also compressed.

Oct. 31, 2011

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.

by Henri Verbeet

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.

Oct. 31, 2011

Re: [PATCH 2/5] wined3d: Create the DIB section for DDSCAPS_OWNDC surfaces on initialization.

by Stefan Dösinger

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.

Oct. 31, 2011

Re: [PATCH 4/5] wined3d: Make the buffer parameter to buffer_is_dirty() const.

by Henri Verbeet

On 31 October 2011 19:56, Josh Juran <josh(a)iswifter.net> wrote: > Looks like you lost an 'inline'. Was that intentional? > Yes.

Oct. 31, 2011

Re: [PATCH 4/5] wined3d: Make the buffer parameter to buffer_is_dirty() const.

by Josh Juran

On Oct 31, 2011, at 11:48 AM, Henri Verbeet wrote: > --- > dlls/wined3d/buffer.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/buffer.c b/dlls/wined3d/buffer.c > index 45518cc..69c110a 100644 > --- a/dlls/wined3d/buffer.c > +++ b/dlls/wined3d/buffer.c > @@ -76,9 +76,9 @@ static inline void buffer_clear_dirty_areas(struct wined3d_buffer *This) > This->modified_areas = 0; > } > > -static inline BOOL buffer_is_dirty(struct wined3d_buffer *This) > +static BOOL buffer_is_dirty(const struct wined3d_buffer *buffer) > { > - return !!This->modified_areas; > + return !!buffer->modified_areas; > } > > static inline BOOL buffer_is_fully_dirty(struct wined3d_buffer *This) > -- Looks like you lost an 'inline'. Was that intentional? Josh

Oct. 31, 2011