February 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 1/7] wined3d: Restore the pixel format of the window whose pixel format was actually changed. (try 2)

by Ken Thomases

On Feb 14, 2014, at 11:52 AM, Henri Verbeet wrote: > On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: >> -static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx, int pf) >> +static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx) > This doesn't need "gl_info" either anymore now. It's also a bit > questionable if context_restore_gl_context() has much of a purpose at > all anymore, it's pretty much just a wglMakeCurrent() call, and has > only two callers. When I implement WGL_WINE_make_current, it will be more complicated again and will need gl_info to check if the extension is supported. (I actually already have that implemented locally. I've been waiting for this pixel format stuff to clear before submitting it.) -Ken

Feb. 14, 2014

Re: xmllite: Don't fail the whole parsing process because of unsupported 'xmlns' attribute.

by Dmitry Timoshkov

Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Do you plan to add more code to xmllite itself or what we have is enough > for taskschd so far? With currectly sent fixes for xmllite I was able to successfully parse pretty complex XML task definitions imported using Tasks Scheduler UI from Windows7. At some point I will also need to generate XML task defs, and I haven't tested that xmllite functionality yet. As long as I don't find other bugs in xmllite I have no plans to spend more time on it. -- Dmitry.

Feb. 14, 2014

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.

by Henri Verbeet

On 13 February 2014 23:10, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * Unfortunately different implementations(Windows-NV and Mac-AMD tested) interpret some colors vastly > + * differently, so we need a max diff of 18. */ And actually, is there any chance the "vastly differently" here is because of using BT.601 vs. BT.709 coefficients, or not including the headroom/footroom scaling + offsets?

Feb. 14, 2014

Re: [PATCH 1/5] d3d9/tests: Clean up yuv_color_test.

by Henri Verbeet

On 13 February 2014 23:10, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - HRESULT color; > - DWORD ref_color_left, ref_color_right; > + DWORD ref_color_left, ref_color_right, color; > If you're cleaning it up anyway, you may as well make that a D3DCOLOR. > + static const struct > + { > + DWORD in; /* The input color. */ > + DWORD uyvy_left; /* "in" interpreted as uyvy and transformed to RGB, pixel 1/1. */ > + DWORD uyvy_right; /* "in" interpreted as uyvy and transformed to RGB, pixel 2/1. */ > + DWORD yuy2_left; /* "in" interpreted as yuy2 and transformed to RGB, pixel 1/1. */ > + DWORD yuy2_right; /* "in" interpreted as yuy2 and transformed to RGB, pixel 2/1. */ > + } > + test_data[] = > + { > + {0x00000000, 0x00008700, 0x00008700, 0x00008700, 0x00008700}, > + {0xff000000, 0x00008700, 0x004bff1c, 0x00b30000, 0x00b30000}, > + {0x00ff0000, 0x00b30000, 0x00b30000, 0x00008700, 0x004bff1c}, > + {0x0000ff00, 0x004bff1c, 0x00008700, 0x000030e1, 0x000030e1}, > + {0x000000ff, 0x000030e1, 0x000030e1, 0x004bff1c, 0x00008700}, > + {0xffff0000, 0x00b30000, 0x00ffd01c, 0x00b30000, 0x00ffd01c}, > + {0xff00ff00, 0x004bff1c, 0x004bff1c, 0x00b300e1, 0x00b300e1}, > + {0xff0000ff, 0x000030e1, 0x004bffff, 0x00ffd01c, 0x00b30000}, > + {0x00ffff00, 0x00ffd01c, 0x00b30000, 0x000030e1, 0x004bffff}, > + {0x00ff00ff, 0x00b300e1, 0x00b300e1, 0x004bff1c, 0x004bff1c}, > + {0x0000ffff, 0x004bffff, 0x000030e1, 0x004bffff, 0x000030e1}, > + {0xffffff00, 0x00ffd01c, 0x00ffd01c, 0x00b300e1, 0x00ff79ff}, > + {0xffff00ff, 0x00b300e1, 0x00ff79ff, 0x00ffd01c, 0x00ffd01c}, > + {0xffffffff, 0x00ff79ff, 0x00ff79ff, 0x00ff79ff, 0x00ff79ff}, > + {0x4cff4c54, 0x00ff0000, 0x00ff0000, 0x000b8b00, 0x00b6ffa3}, > + {0x00800080, 0x00000000, 0x00000000, 0x0000ff00, 0x0000ff00}, > + {0xff80ff80, 0x00ffffff, 0x00ffffff, 0x00ff00ff, 0x00ff00ff}, > + {0x1c6b1cff, 0x000000fd, 0x000000fd, 0x006dff45, 0x0000d500}, > }; ... > - for(fmt = 0; fmt < 2; fmt++) { > - if(fmt == 0) { > - format = D3DFMT_UYVY; > - fmt_string = "D3DFMT_UYVY"; > - } else { > + for (fmt = 0; fmt < 2; fmt++) > + { > + if (fmt) > + { > format = D3DFMT_YUY2; > fmt_string = "D3DFMT_YUY2"; > } > + else > + { > + format = D3DFMT_UYVY; > + fmt_string = "D3DFMT_UYVY"; > + } ... > + if (fmt) > + { > ref_color_left = test_data[i].yuy2_left; > ref_color_right = test_data[i].yuy2_right; > } > + else > + { > + ref_color_left = test_data[i].uyvy_left; > + ref_color_right = test_data[i].uyvy_right; > + } > There's probably a nicer way to do all that.

Feb. 14, 2014

Re: [PATCHv5 3/3] d3d9/tests: Add tests for different YUV texture layouts

by Henri Verbeet

On 13 February 2014 14:52, Martin Storsjo <martin(a)martin.st> wrote: > + IDirect3DSurface9 *surface = NULL, *target = NULL; You don't need those to be NULL. > + HRESULT color; You'll want to use D3DCOLOR instead of HRESULT here. > + /* Some (all?) Windows drivers do not support YUV 3D textures, only 2D surfaces in > + * StretchRect. Thus use StretchRect to draw the YUV surface onto the screen instead > + * of drawPrimitive. */ > + if (IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, 0, > + D3DRTYPE_SURFACE, format) != D3D_OK) > + { > + skip("%s is not supported.\n", fmt_string); > + continue; > + } You should also verify the StretchRect() is supported with CheckDeviceFormatConversion(). > + BYTE Y = (color >> 16) & 0xff; > + BYTE U = (color >> 8) & 0xff; > + BYTE V = (color >> 0) & 0xff; It's probably just as easy to just store the separate components to begin with. > + hr = IDirect3DDevice9_StretchRect(device, surface, NULL, target, NULL, D3DTEXF_POINT); > + ok(hr == D3D_OK, "IDirect3DDevice9_StretchRect failed with %#x.\n", hr); > + > + /* Native D3D can't resist filtering the YUY surface, even though we asked it not to > + * do so above. To prevent running into precision problems, read at points with some > + * margin within the rect. */ That's not technically true, no filtering would be D3DTEXF_NONE. I don't know if that's going to make a difference in practice though.

Feb. 14, 2014

Re: [PATCHv4 2/3] wined3d: Use an rbtree for storing shaders for texture format conversion/blitting

by Henri Verbeet

On 13 February 2014 13:05, Martin Storsjo <martin(a)martin.st> wrote: > static HRESULT arbfp_blit_alloc(struct wined3d_device *device) > { > + struct arbfp_blit_priv *priv; > device->blit_priv = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct arbfp_blit_priv)); > if(!device->blit_priv) { > ERR("Out of memory\n"); > return E_OUTOFMEMORY; > } > + priv = device->blit_priv; > + > + if (wine_rb_init(&priv->shaders, &wined3d_arbfp_blit_rb_functions) == -1) > + { > + ERR("Failed to initialize rbtree.\n"); > + HeapFree(GetProcessHeap(), 0, device->blit_priv); > + device->blit_priv = NULL; > + return E_OUTOFMEMORY; > + } > + > return WINED3D_OK; > } > The following is probably slightly nicer: static HRESULT arbfp_blit_alloc(struct wined3d_device *device) { - device->blit_priv = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct arbfp_blit_priv)); - if(!device->blit_priv) { - ERR("Out of memory\n"); + struct arbfp_blit_priv *priv; + + if (!(priv = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(*priv)))) return E_OUTOFMEMORY; + + if (wine_rb_init(&priv->shaders, &wined3d_arbfp_blit_rb_functions) == -1) + { + ERR("Failed to initialize rbtree.\n"); + HeapFree(GetProcessHeap(), 0, priv); + return E_FAIL; } + + device->blit_priv = priv; + return WINED3D_OK; } > + if (desc) > + HeapFree(GetProcessHeap(), 0, desc); There's no point in checking for NULL before HeapFree(). Perhaps more importantly, I think it makes more sense to insert the rbtree entries in arbfp_blit_set(), instead of duplicating the code between gen_p8_shader() and gen_yuv_shader().

Feb. 14, 2014

Re: [PATCH 4/7] ddraw/tests: Test that DirectDraw7 doesn't modify the pixel format of the window it targets.

by Henri Verbeet

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > dlls/ddraw/tests/Makefile.in | 2 +- > dlls/ddraw/tests/ddraw7.c | 161 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 162 insertions(+), 1 deletion(-) > For what it's worth, I think it's fine to fold the ddraw tests into a single patch, but splitting them like this is fine too.

Feb. 14, 2014

Re: [PATCH 4/7] ddraw/tests: Test that DirectDraw7 doesn't modify the pixel format of the window it targets.

by Henri Verbeet

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > --- > dlls/ddraw/tests/Makefile.in | 2 +- > dlls/ddraw/tests/ddraw7.c | 161 +++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 162 insertions(+), 1 deletion(-) > For what it's worth, I think it's fine to fold the ddraw tests into a single patch, but splitting them like this is fine too.

Feb. 14, 2014

Re: [PATCH 2/7] d3d9/tests: Test that Direct3D9 doesn't modify the pixel format of the window it targets. (try 3)

by Henri Verbeet

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > + /* If no opengl32 function has been called, GetPixelFormat() doesn't reflect a > + prior SetPixelFormat(). So, call wglCreateContext() even though it will fail. */ > + hglrc = wglCreateContext(hdc); > + ok(hglrc == NULL, "wglCreateContext succeeded when no pixel format has been set\n"); > + if (hglrc) wglDeleteContext(hglrc); I decided to look into this a bit, but could only reproduce it on the testbot. It seems just loading opengl32 is enough to make GetPixelFormat() work. (Also see https://newtestbot.winehq.org/JobDetails.pl?Key=4908.)

Feb. 14, 2014

Re: [PATCH 1/7] wined3d: Restore the pixel format of the window whose pixel format was actually changed. (try 2)

by Henri Verbeet

On 14 February 2014 00:31, Ken Thomases <ken(a)codeweavers.com> wrote: > -static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx, int pf) > +static void context_restore_gl_context(const struct wined3d_gl_info *gl_info, HDC dc, HGLRC gl_ctx) This doesn't need "gl_info" either anymore now. It's also a bit questionable if context_restore_gl_context() has much of a purpose at all anymore, it's pretty much just a wglMakeCurrent() call, and has only two callers.

Feb. 14, 2014