January 2017 - Wine-Devel - list.winehq.org

RE : Re: [PATCH 1/3] wined3d: Add some missing state updates for buffer textures.

by Guillaume Charifi

Right, thank you... -------- Message d'origine -------- De : Bruno Jesus <00cpxxx(a)gmail.com> Date :29/01/2017 03:13 (GMT+01:00) À : Guillaume Charifi Cc : Wine Develop Objet : Re: [PATCH 1/3] wined3d: Add some missing state updates for buffer textures. On Sat, Jan 28, 2017 at 8:46 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > --- > dlls/wined3d/context.c | 12 ++++++++++++ > dlls/wined3d/state.c | 5 +++++ > dlls/wined3d/view.c | 6 ------ > 3 files changed, 17 insertions(+), 6 deletions(-) You missed the Signed-off-by, see the red marks at http://source.winehq.org/patches/

Jan. 29, 2017

Re: [PATCH 1/3] wined3d: Add some missing state updates for buffer textures.

by Bruno Jesus

On Sat, Jan 28, 2017 at 8:46 PM, Guillaume Charifi <guillaume.charifi(a)sfr.fr> wrote: > --- > dlls/wined3d/context.c | 12 ++++++++++++ > dlls/wined3d/state.c | 5 +++++ > dlls/wined3d/view.c | 6 ------ > 3 files changed, 17 insertions(+), 6 deletions(-) You missed the Signed-off-by, see the red marks at http://source.winehq.org/patches/

Jan. 29, 2017

Re: [PATCH v3 1/4] ddraw: Don't crash if writing out a new ddraw1 surface segfaults.

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 https://testbot.winehq.org/JobDetails.pl?Key=28113 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:1662: Test failed: Got unexpected color 0x000000ff.

Jan. 28, 2017

Re: [PATCH v3 1/4] ddraw: Don't crash if writing out a new ddraw1 surface segfaults.

by Sebastian Lackner

On 28.01.2017 22:59, Alex Henrie wrote: > + __TRY > { > - *surface = NULL; > - return hr; > + if (FAILED(hr)) > + { > + *surface = NULL; > + return hr; > + } Its not possible to use return in a __TRY block.

Jan. 28, 2017

Re: [v2 PATCH 3/3] windowscodecs: Add support for palette image formats to PNG encoder.

by Sebastian Lackner

On 27.01.2017 22:28, Vincent Povirk wrote: >> + else >> + { >> + png_palette[i].red = 0; >> + png_palette[i].green = 0; >> + png_palette[i].blue = 0; >> + } > > Why is it necessary to pad the palette in this way? Couldn't you just > pass the appropriate number of colors? > > Clamping to 1 << This->format->bit_depth is necessary (see the comment about newer libpng versions), but padding the palette probably isn't, at least I'm not aware of any test for it. It should be fine to replace colors = 1 << This->format->bit_depth; with colors = min(This->colors, 1 << This->format->bit_depth); and to remove the else branch.

Jan. 28, 2017

Re: [PATCH 1/5] wined3d: Fix sRGB clears with no support for ARB_framebuffer_sRGB.

by Matteo Bruni

2017-01-27 22:29 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 27 January 2017 at 22:22, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >> Yes, the idea is to do the "manual" sRGB correction of the clear color >> when ARB_framebuffer_sRGB is not supported even if the format doesn't >> advertise WINED3DFMT_FLAG_SRGB_WRITE. >> The story behind this goes like "oh, the test always expects the sRGB >> corrected color, which seems weird for formats / GPUs not supporting >> sRGB. Let me fix the test. Oh, wait, the test now fails on the GF4 Go >> (which doesn't advertise WINED3DFMT_FLAG_SRGB_WRITE for the relevant >> texture format) and actually it was passing before. I guess wined3d is >> wrong then..." >> >> So, this is the fix spurred from that test result, in that we do the >> manual clear color sRGB correction if ARB_framebuffer_sRGB is not >> supported AND we're on d3d9, regardless of the format flags. If >> ARB_framebuffer_sRGB is supported we enable GL_FRAMEBUFFER_SRGB in >> context_apply_clear_state() instead and the condition there should >> still be fine (I think?). > Yes, but now (in d3d9) you'd get sRGB clears on e.g. > WINED3DFMT_B5G6R5_UNORM when ARB_framebuffer_sRGB is not supported, > while you wouldn't (necessarily) when it is. Ahhh, you're right, I didn't think of that. Hmm, not sure how to fix it properly then without introducing more flags... I guess first of all I should check what happens when clearing those never-supposed-to-be-sRGB formats.

Jan. 27, 2017

Re: [PATCH 1/5] wined3d: Fix sRGB clears with no support for ARB_framebuffer_sRGB.

by Henri Verbeet

On 27 January 2017 at 22:22, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Yes, the idea is to do the "manual" sRGB correction of the clear color > when ARB_framebuffer_sRGB is not supported even if the format doesn't > advertise WINED3DFMT_FLAG_SRGB_WRITE. > The story behind this goes like "oh, the test always expects the sRGB > corrected color, which seems weird for formats / GPUs not supporting > sRGB. Let me fix the test. Oh, wait, the test now fails on the GF4 Go > (which doesn't advertise WINED3DFMT_FLAG_SRGB_WRITE for the relevant > texture format) and actually it was passing before. I guess wined3d is > wrong then..." > > So, this is the fix spurred from that test result, in that we do the > manual clear color sRGB correction if ARB_framebuffer_sRGB is not > supported AND we're on d3d9, regardless of the format flags. If > ARB_framebuffer_sRGB is supported we enable GL_FRAMEBUFFER_SRGB in > context_apply_clear_state() instead and the condition there should > still be fine (I think?). Yes, but now (in d3d9) you'd get sRGB clears on e.g. WINED3DFMT_B5G6R5_UNORM when ARB_framebuffer_sRGB is not supported, while you wouldn't (necessarily) when it is.

Jan. 27, 2017

Re: [v2 PATCH 3/3] windowscodecs: Add support for palette image formats to PNG encoder.

by Vincent Povirk

> + else > + { > + png_palette[i].red = 0; > + png_palette[i].green = 0; > + png_palette[i].blue = 0; > + } Why is it necessary to pad the palette in this way? Couldn't you just pass the appropriate number of colors?

Jan. 27, 2017

Re: [PATCH 1/5] wined3d: Fix sRGB clears with no support for ARB_framebuffer_sRGB.

by Matteo Bruni

2017-01-27 22:00 GMT+01:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 27 January 2017 at 19:52, Matteo Bruni <mbruni(a)codeweavers.com> wrote: >> - if (!gl_info->supported[ARB_FRAMEBUFFER_SRGB] && needs_srgb_write(context, state, fb)) >> + if (!gl_info->supported[ARB_FRAMEBUFFER_SRGB] >> + && ((!(context->d3d_info->wined3d_creation_flags & WINED3D_SRGB_READ_WRITE_CONTROL) >> + && fb->render_targets[0] && fb->render_targets[0]->format_flags & WINED3DFMT_FLAG_SRGB_WRITE) >> + || state->render_states[WINED3D_RS_SRGBWRITEENABLE])) > I think this looks suspicious, why is this more correct? > In particular, wouldn't this enable sRGB clears on formats without > WINED3DFMT_FLAG_SRGB_WRITE? Patch 2/5 hints that that may be > intentional, but in that case, shouldn't this be independent of > ARB_framebuffer_sRGB support? Yes, the idea is to do the "manual" sRGB correction of the clear color when ARB_framebuffer_sRGB is not supported even if the format doesn't advertise WINED3DFMT_FLAG_SRGB_WRITE. The story behind this goes like "oh, the test always expects the sRGB corrected color, which seems weird for formats / GPUs not supporting sRGB. Let me fix the test. Oh, wait, the test now fails on the GF4 Go (which doesn't advertise WINED3DFMT_FLAG_SRGB_WRITE for the relevant texture format) and actually it was passing before. I guess wined3d is wrong then..." So, this is the fix spurred from that test result, in that we do the manual clear color sRGB correction if ARB_framebuffer_sRGB is not supported AND we're on d3d9, regardless of the format flags. If ARB_framebuffer_sRGB is supported we enable GL_FRAMEBUFFER_SRGB in context_apply_clear_state() instead and the condition there should still be fine (I think?).

Jan. 27, 2017

Re: [PATCH 1/5] wined3d: Fix sRGB clears with no support for ARB_framebuffer_sRGB.

by Henri Verbeet

On 27 January 2017 at 19:52, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > - if (!gl_info->supported[ARB_FRAMEBUFFER_SRGB] && needs_srgb_write(context, state, fb)) > + if (!gl_info->supported[ARB_FRAMEBUFFER_SRGB] > + && ((!(context->d3d_info->wined3d_creation_flags & WINED3D_SRGB_READ_WRITE_CONTROL) > + && fb->render_targets[0] && fb->render_targets[0]->format_flags & WINED3DFMT_FLAG_SRGB_WRITE) > + || state->render_states[WINED3D_RS_SRGBWRITEENABLE])) I think this looks suspicious, why is this more correct? In particular, wouldn't this enable sRGB clears on formats without WINED3DFMT_FLAG_SRGB_WRITE? Patch 2/5 hints that that may be intentional, but in that case, shouldn't this be independent of ARB_framebuffer_sRGB support?

Jan. 27, 2017