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

Re: Fixing up the code style

by Martin Storsjö

On Thu, 13 Feb 2014, Stefan Dösinger wrote: > Martin, Michael or Sebastian: If you are reading this thread maybe you > can share your thoughts from the point of view of someone who isn't a > long-term contributor. I'll try to stay out of the rest of this discussion, but I can at least agree that it's hard to get the coding style right when all the surrounding code is consistently (more or less) in another style, and the pointed out "good style" example files don't use all features (cs.c didn't have any switch cases). // Martin

Feb. 13, 2014

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

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks good, thanks! Wrt the testbot failures: It looks like CheckDeviceFormatConversion is in fact the right way to check this - I missed a sentence in the msdn page. I'll send a patch to handle this in this test and yuv_color_test. Real Windows drivers seem to agree with our interpretation of CheckDeviceFormatConversion. (Sorry if this mail arrives twice. I think my mail server swallowed the last one.) Am 2014-02-13 14:52, schrieb Martin Storsjo: > There are no public defines for the YV12 and NV12 > formats, although they do seem to be supported on > actual D3D on windows, at least on the one machine I > tested on. > --- > Removed unnecessary IDirect3DDevice9_SetFVF call. > --- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/NuWAAoJEN0/YqbEcdMwg+0P/iXXzioHwCQuR4fQxmaZ0iQa FB/3kQd1E2Gn/k0sV9H+Uqb0s+C6g1/QSk11Q4+KaYjmAgcp7j2BJXi81wksInRV wLix2vEqENroLxoDbVVcjEyvlLBENnkCU88ixzK2IjzDuMGrDBNX6xnpDgE7UQIT ra5JiO6hnY2J6LN78QXomwgIQgtbTURhR+NwyXbYk6uYhWGu3+JoB24Ga0NnRH/p zfNXEWYgcrW05lBUCBEwu7+7XHHaYY45l8/p5o33JqiacYJIvFlwJ/H/Kpcc4bQ1 4yky4k/K2DEwpdlhBAzsGheqs5mAZ7xCYytFH+f1kNbDAfowN9M03wgFjfecPPJa 2UENwr0otG2/NdYyqD4FbfLUQZYnAcP4OdZ2lTIE/oZqlsN7T3d7xVhfzqDjRWP+ NhsCfKFTct+v0DWZpqp9Gcyi2aOJtoxuRFpaQIUHcKnEDD6PzBCLutVVERrhI3Gy 55+j7FfH9MfDT08+EOhK+4VXu74CdIgTUaR2Hm2nZFFw9q4Awh4Ixkd4RjjGFAWP RDnNzInSeaBKFYlwHhIxt5lnnVdIsJTkRvQi+j7g3j9YBMncE88YFWWw8wqkmPaE 9QfCvMCQZp7qmf9ak8A2PfCNDQv4jx4LEoJoNjgloLm8qQq0Yu+JYRpNjyvC6MJa pfw1CcMzFR626dZ9dOW2 =69kR -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: Fixing up the code style

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-13 14:57, schrieb Jacek Caban: > Well, another solution is to be less picky about coding style > during reviews. You gave me a perfect example just after writing > this mail: > > http://www.winehq.org/pipermail/wine-devel/2014-February/102864.html > > I'm mostly talking about the second comment. Seriously? Is that > worth a resend? Maybe, or maybe not. The basic issue still stands. New contributors will look at the existing code, and if its inconsistent how are they supposed to write code that's consistent in itself. That's not a question of pickiness but approach to the problem. Take a look at e.g. http://www.winehq.org/pipermail/wine-patches/2014-February/130297.html . It has plenty of inconsistencies, and none of them are the contributor's fault. Should we ignore that as well? If so, should we allow the codebase to look like that? My impression was that the answers to that were no and no, with the idea that the problem will be fixed by unifying the style together with other, functional changes. That way we end up with picky reviews and IMO that approach is bad. Martin, Michael or Sebastian: If you are reading this thread maybe you can share your thoughts from the point of view of someone who isn't a long-term contributor. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/NWiAAoJEN0/YqbEcdMw0WAP/3pxrgE8BZhrFZtdVipd10Yv 8gwg9uB9fzWJfrcjiBoXiCUn7UHLKs3pmsAp/2VtwPVLC1mgAnNOH3uvKW94oz/3 w2jymggEuRr9Xu8CCAu/fcJmg3sLhu/OGM2edwmos5QS82R5oNs+92FStlw2aACM PMAV3Qgt1CLFFRIi/AH5bFHUqb3finphKWl4B2H50s3E3RSxJYkYN2Y8GsdqXdi7 xl/g/QbMWhICddjqbiLreSrRt1I92KIYizCpjK2yhWRlrpk/eDB1CjspsxS1j1+l H2dTLEq7+tL4I3tjoBQs9T/Inz5sgeor6satQqxJYzOaRr0GJrG7egzBId9pAmmP YpOxYr06MRmebDmVjRf388kL2bVZy6IA0dE7EM1dX0X6qJL8pTwjM6FfME10+ijO WVb1scOsTsS8SRSy2LvVmCo0UlUb2/EtADJct91i2nxI5Bdoge3131BBxOr6QIFg 4mywxT1+xPkrJAwVa8vs3R6gQZiNNIZ5Fe9/mP8LkgKTVCB5qMO12UY5a8QRacsf FnPpbVbI4hXxbkftqOTrFGUNUruEEJYLm2jX6fInZ6Jsx86Ix9Lwa1jtGujJIUkH Iki9EvZLX0Qh+BlI+0+A7csbypftbkT+b8WQG7NwXpIX8j38yrtJaFqEInCoHzDM KzyT7fE5o2u5QW3G/WtX =O2Cu -----END PGP SIGNATURE-----

Feb. 13, 2014

Re: Fixing up the code style

by Henri Verbeet

On 13 February 2014 14:57, Jacek Caban <jacek(a)codeweavers.com> wrote: > often no clear answer if it's worth or not. However, my feeling is that > d3d reviewers tend to be way more picky about that than others and maybe > we could solve most of the problems on reviewers' side. I'm not quite sure where you got that impression, in the general case anyway. Personally, I'll point out style issues if the patch is going to need changes anyway, but I'm not going to ask somebody to redo a patch for style reasons alone, unless it's wildly inconsistent. For the record, I think this thread is a waste of time, and would otherwise have ignored it.

Feb. 13, 2014

Re: Fixing up the code style

by Jacek Caban

On 02/13/14 14:09, Stefan Dösinger wrote: > Hi, > > After recently helping two contributors (the Pipelight guys and Martin > Storsjö) through the maze of the Wine code style I think it's best to > lift the ban against style-only patches and unify the code style once > and for all. > > The basic reasoning is that from my point of view the lack of clarity > wrt the code style and lack of automatic enforceability is causing > more issues than the problems style-only patches cause with git blame. > Finding a style-only change with git blame can be handled by running > git blame again. Frustrating contributors on the other hand has no > workaround. > > So I propose to agree on a code style for the entire project, fixing > it up preferably with an automated tool and in the future enforcing > the style with checks in the Testbot. > > Opinions? Well, another solution is to be less picky about coding style during reviews. You gave me a perfect example just after writing this mail: http://www.winehq.org/pipermail/wine-devel/2014-February/102864.html I'm mostly talking about the second comment. Seriously? Is that worth a resend? I know it's often tempting to ask for code style change and there is often no clear answer if it's worth or not. However, my feeling is that d3d reviewers tend to be way more picky about that than others and maybe we could solve most of the problems on reviewers' side. Note that I'm not saying that no code style comments should be made, but those could be limited to cases that really make sense. > Wrt the code style I propose the style that is used in wineserver. It > is the same one as the new style in the d3d code except for > single-line if conditions. There is another problem with coding style than git blame... No, I don't want this style. I hate new lines for each opening bracket like: if(x) { x = 0; y = 1; } This makes the code almost 2 times longer than it needs to be for no good reason. If you need more space to make code cleaner, simply add a blank line where they are useful, not for every bracket. Let's use jscript style ;) Cheers, Jacek

Feb. 13, 2014

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

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-13 14:25, schrieb Martin Storsjo: > + hr = IDirect3DDevice9_SetFVF(device, D3DFVF_XYZ | > D3DFVF_TEX0); + ok(hr == D3D_OK, "IDirect3DDevice9_SetFVF > failed, hr = %#x.\n", hr); Another issue I missed: This call is not needed because you don't call DrawPrimitive and friends. I'll send a patch to clean up the same problems I pointed out here in yuv_color_test. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/MzZAAoJEN0/YqbEcdMwZysQAIt75Q8zVg7KHGGuTDPPjq+G vtUI+xZryYVHSubEDG7uawf3L9n3QEdF6l5RIEEi7p40NPG9zf7P2eGGrIOoVpqY L5j1WAhnseHVO6e+vuB0/9M4RvSGHMzdTmzsdIz2/LiGgq3ui13semLC10NvybNy nmSNhU4umJAHR/Ize+3UHwgxOmyhyJvZ6I1ieMdprxmmC8LeOM+BAeY+hPZ6T671 jqwK64hRxCJVZdcqbHIV/0SAoFPoy9ndDZvcOe/a0FSqPQJGKCRWVDWd/JF2vH0p utAQcw9exQUga4F+0ds/60TMOVT87V+O4yyV81HeF+eYXR3U7W/IgvNPtvZW/HIM 0QMHYBEXKOLKXmqB2QONBC92l0TZcMZ3prXscexwpsOVMWyr6OHKYDBuo4Doc7av 3bPR9SGDY/V2wCJLIdjXZIWWO9C35JYDN2hrtyhAaCoIN2CBJDsqCPBbA4NcYFiy UOQB9QPExcK0f/Jg2Gqx1nbQ3lqMuCwOz8l3nv4Xwf/sJDbB2WXm6pllR/dmXppG DKx3G9/CrZkKukaSH93BNj9a1BDhIkNbA99CffJfuqH3qj7/QB9n4+VLDZQSB9E7 ykL4qXxXMZcUT47BtHS6wWV/QqRPtW3cG3/a0EUI03+WclYYt0V6KJX3izQEu6Fm XUUxgRjpsTexsjs6Hk/o =xV6C -----END PGP SIGNATURE-----

Feb. 13, 2014

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

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, There are two more style issues I missed in my previous reviews: > + static const struct > + { > + DWORD color1, color2; > + DWORD rgb1, rgb2; > + } > + test_data[] = > + { > + { 0x000000, 0xffffff, 0x00008800, 0x00ff7dff }, > + { 0xff0000, 0x00ffff, 0x004aff14, 0x00b800ee }, > + { 0x00ff00, 0xff00ff, 0x000024ee, 0x00ffe114 }, > + { 0x0000ff, 0xffff00, 0x00b80000, 0x004affff }, > + { 0xffff00, 0x0000ff, 0x004affff, 0x00b80000 }, > + { 0xff00ff, 0x00ff00, 0x00ffe114, 0x000024ee }, > + { 0x00ffff, 0xff0000, 0x00b800ee, 0x004aff14 }, > + { 0xffffff, 0x000000, 0x00ff7dff, 0x00008800 }, 4 space indents in the data block. > + DWORD color = (x < width/2 && y < height/2) ? test_data[i].color1 : test_data[i].color2; Please use spaces consistently around binary opertions. (i.e. x < width / 2) etc. I think I've also seen some multiplications that are affected. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/MXbAAoJEN0/YqbEcdMwJjQP/2OzFt2DE5iEhWuwTOACdXSM 1dhlZnmz4bH+sUymen1dvxIXCLxhKWlLGl5cPkkFk2OCj0B2YlYaheV4qDJj5Cye zfKyrKjv1nfwk86g5YepoS2Ee/ZUdiMkNF+5tq9FkAa5LjStTgpC4KU6Vxpye1i5 Wmv2IBc0jAe84pRoDuZGYt0CT/RqgdHo8yvouK6Z5ytS7ClpLYWrLt/FYhpk0Sjj ITa6l7NksgBVN4ByZW5Pyk9Hf8gZ44qx9J8rzxOGBxLkGGpTOuGLB9MsE4riYwGy M1X10s7llWCs7Qy8Hs96Gg4vfHMS09xgfuYlj3UBKaXJVyRhTIDJpc7iqXA4WDaN mWJUrVaHCPha6ZGW2llC43wh5zECMH1/v98veRICbYqFhlKFzWuhtLq4BOwloJj4 fvJaYivFhkyDsn1y5grO8dGYjirZFNkiG/dIj7XpO8lh+4xGuTrBCO5hWBqICLV2 uQX6woh2MKv7ddFmRdvUuL/emV8oKBKga9t8LgTQdeSX7v//5aPtCLeawPKczpIB yPv2zUIei3G5TAcLlter66KGyvQZgXhiZXwtwq0wCWvNWRitjTztLp+2jrg9uWJ1 JiuhXuBFbsI8r/iiTrYXmZv1vX6BBFfL8I59SS0+J/7dFFZ63F5ePqEsl0WKSQ0W 0haQuTaKNLiVBlP1pmkF =fSNX -----END PGP SIGNATURE-----

Feb. 13, 2014

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

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks good to me. Am 2014-02-13 13:05, schrieb Martin Storsjo: > --- Fixed the final style issues and added comments about who > activates the GL context. --- dlls/wined3d/arb_program_shader.c | > 204 +++++++++++++++++++++++++------------- 1 file changed, 134 > insertions(+), 70 deletions(-) > > diff --git a/dlls/wined3d/arb_program_shader.c > b/dlls/wined3d/arb_program_shader.c index 93a6e31..a273eac 100644 > --- a/dlls/wined3d/arb_program_shader.c +++ > b/dlls/wined3d/arb_program_shader.c @@ -6768,22 +6768,74 @@ const > struct fragment_pipeline arbfp_fragment_pipeline = { > arbfp_fragmentstate_template, }; > > -struct arbfp_blit_priv { - GLenum yuy2_rect_shader, > yuy2_2d_shader; - GLenum uyvy_rect_shader, uyvy_2d_shader; - > GLenum yv12_rect_shader, yv12_2d_shader; - GLenum > nv12_rect_shader, nv12_2d_shader; - GLenum p8_rect_shader, > p8_2d_shader; +struct arbfp_blit_type +{ + enum complex_fixup > fixup; + GLenum textype; +}; + +struct arbfp_blit_desc +{ + > GLenum shader; + struct arbfp_blit_type type; + struct > wine_rb_entry entry; +}; + +struct arbfp_blit_priv +{ + struct > wine_rb_tree shaders; GLuint palette_texture; }; > > +static int arbfp_blit_type_compare(const void *key, const struct > wine_rb_entry *entry) +{ + const struct arbfp_blit_type *ka = > key; + const struct arbfp_blit_type *kb = > &WINE_RB_ENTRY_VALUE(entry, const struct arbfp_blit_desc, > entry)->type; + + if (ka->fixup != kb->fixup) + return > ka->fixup < kb->fixup ? -1 : 1; + if (ka->textype != > kb->textype) + return ka->textype < kb->textype ? -1 : 1; + > return 0; +} + +/* Context activation is done by the caller. */ > +static void arbfp_free_blit_shader(struct wine_rb_entry *entry, > void *context) +{ + const struct wined3d_gl_info *gl_info = > context; + struct arbfp_blit_desc *entry_arb = > WINE_RB_ENTRY_VALUE(entry, struct arbfp_blit_desc, entry); + + > GL_EXTCALL(glDeleteProgramsARB(1, &entry_arb->shader)); + > checkGLcall("glDeleteProgramsARB(1, &entry_arb->shader)"); + > HeapFree(GetProcessHeap(), 0, entry_arb); +} + +const struct > wine_rb_functions wined3d_arbfp_blit_rb_functions = +{ + > wined3d_rb_alloc, + wined3d_rb_realloc, + wined3d_rb_free, + > arbfp_blit_type_compare, +}; + 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; } > > @@ -6793,17 +6845,8 @@ static void arbfp_blit_free(struct > wined3d_device *device) const struct wined3d_gl_info *gl_info = > &device->adapter->gl_info; struct arbfp_blit_priv *priv = > device->blit_priv; > > - GL_EXTCALL(glDeleteProgramsARB(1, &priv->yuy2_rect_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->yuy2_2d_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->uyvy_rect_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->uyvy_2d_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->yv12_rect_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->yv12_2d_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->nv12_rect_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->nv12_2d_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->p8_rect_shader)); - > GL_EXTCALL(glDeleteProgramsARB(1, &priv->p8_2d_shader)); - > checkGLcall("Delete yuv and p8 programs"); + > wine_rb_destroy(&priv->shaders, arbfp_free_blit_shader, > &device->adapter->gl_info); + checkGLcall("Delete blit > programs"); > > if (priv->palette_texture) gl_info->gl_ops.gl.p_glDeleteTextures(1, > &priv->palette_texture); @@ -7196,12 +7239,14 @@ static BOOL > gen_nv12_read(struct wined3d_shader_buffer *buffer, GLenum > textype, return TRUE; } > > +/* Context activation is done by the caller. */ static GLuint > gen_p8_shader(struct arbfp_blit_priv *priv, const struct > wined3d_gl_info *gl_info, GLenum textype) { GLenum shader; struct > wined3d_shader_buffer buffer; GLint pos; + struct > arbfp_blit_desc *desc; > > /* Shader header */ if (!shader_buffer_init(&buffer)) @@ -7249,14 > +7294,34 @@ static GLuint gen_p8_shader(struct arbfp_blit_priv > *priv, shader_arb_dump_program_source(buffer.buffer); } > > - if (textype == GL_TEXTURE_RECTANGLE_ARB) - > priv->p8_rect_shader = shader; - else - > priv->p8_2d_shader = shader; - shader_buffer_free(&buffer); > > + desc = HeapAlloc(GetProcessHeap(), 0, sizeof(*desc)); + if > (!desc) + { + ERR("Out of memory\n"); + goto > err_out; + } + + desc->type.textype = textype; + > desc->type.fixup = COMPLEX_FIXUP_P8; + desc->shader = shader; + > if (wine_rb_put(&priv->shaders, &desc->type, &desc->entry) == -1) + > { + ERR("Out of memory\n"); + goto err_out; + } + > return shader; + +err_out: + GL_EXTCALL(glDeleteProgramsARB(1, > &shader)); + checkGLcall("GL_EXTCALL(glDeleteProgramsARB(1, > &shader))"); + > GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)); + > checkGLcall("glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)"); + > if (desc) + HeapFree(GetProcessHeap(), 0, desc); + return > 0; } > > /* Context activation is done by the caller. */ @@ -7298,6 +7363,7 > @@ static GLuint gen_yuv_shader(struct arbfp_blit_priv *priv, const > struct wined3d_ struct wined3d_shader_buffer buffer; char > luminance_component; GLint pos; + struct arbfp_blit_desc *desc; > > /* Shader header */ if (!shader_buffer_init(&buffer)) @@ -7428,34 > +7494,32 @@ static GLuint gen_yuv_shader(struct arbfp_blit_priv > *priv, const struct wined3d_ > > shader_buffer_free(&buffer); > > - switch (yuv_fixup) + desc = HeapAlloc(GetProcessHeap(), 0, > sizeof(*desc)); + if (!desc) { - case > COMPLEX_FIXUP_YUY2: - if (textype == > GL_TEXTURE_RECTANGLE_ARB) priv->yuy2_rect_shader = shader; - > else priv->yuy2_2d_shader = shader; - break; - - > case COMPLEX_FIXUP_UYVY: - if (textype == > GL_TEXTURE_RECTANGLE_ARB) priv->uyvy_rect_shader = shader; - > else priv->uyvy_2d_shader = shader; - break; - - > case COMPLEX_FIXUP_YV12: - if (textype == > GL_TEXTURE_RECTANGLE_ARB) priv->yv12_rect_shader = shader; - > else priv->yv12_2d_shader = shader; - break; + > ERR("Out of memory\n"); + goto err_out; + } > > - case COMPLEX_FIXUP_NV12: - if (textype == > GL_TEXTURE_RECTANGLE_ARB) - priv->nv12_rect_shader = > shader; - else - priv->nv12_2d_shader = > shader; - break; - default: - > ERR("Unsupported complex fixup: %d\n", yuv_fixup); + > desc->type.textype = textype; + desc->type.fixup = yuv_fixup; + > desc->shader = shader; + if (wine_rb_put(&priv->shaders, > &desc->type, &desc->entry) == -1) + { + ERR("Out of > memory\n"); + goto err_out; } > > return shader; + +err_out: + GL_EXTCALL(glDeleteProgramsARB(1, > &shader)); + checkGLcall("GL_EXTCALL(glDeleteProgramsARB(1, > &shader))"); + > GL_EXTCALL(glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)); + > checkGLcall("glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, 0)"); + > if (desc) + HeapFree(GetProcessHeap(), 0, desc); + return > 0; } > > /* Context activation is done by the caller. */ @@ -7467,6 +7531,8 > @@ static HRESULT arbfp_blit_set(void *blit_priv, struct > wined3d_context *context, enum complex_fixup fixup; const struct > wined3d_gl_info *gl_info = context->gl_info; GLenum textype = > surface->container->target; + struct wine_rb_entry *entry; + > struct arbfp_blit_type type; > > if (surface->flags & SFLAG_CONVERTED) { @@ -7487,39 +7553,37 @@ > static HRESULT arbfp_blit_set(void *blit_priv, struct > wined3d_context *context, > > fixup = get_complex_fixup(surface->resource.format->color_fixup); > > - switch(fixup) + type.fixup = fixup; + type.textype = > textype; + entry = wine_rb_get(&priv->shaders, &type); + if > (entry) { - case COMPLEX_FIXUP_YUY2: - shader = > textype == GL_TEXTURE_RECTANGLE_ARB ? priv->yuy2_rect_shader : > priv->yuy2_2d_shader; - break; - - case > COMPLEX_FIXUP_UYVY: - shader = textype == > GL_TEXTURE_RECTANGLE_ARB ? priv->uyvy_rect_shader : > priv->uyvy_2d_shader; - break; - - case > COMPLEX_FIXUP_YV12: - shader = textype == > GL_TEXTURE_RECTANGLE_ARB ? priv->yv12_rect_shader : > priv->yv12_2d_shader; - break; - - case > COMPLEX_FIXUP_NV12: - shader = textype == > GL_TEXTURE_RECTANGLE_ARB ? priv->nv12_rect_shader : > priv->nv12_2d_shader; - break; - - case > COMPLEX_FIXUP_P8: - shader = textype == > GL_TEXTURE_RECTANGLE_ARB ? priv->p8_rect_shader : > priv->p8_2d_shader; - if (!shader) shader = > gen_p8_shader(priv, gl_info, textype); + struct > arbfp_blit_desc *desc = WINE_RB_ENTRY_VALUE(entry, struct > arbfp_blit_desc, entry); + shader = desc->shader; + } + > else + { + switch (fixup) + { + case > COMPLEX_FIXUP_P8: + shader = gen_p8_shader(priv, > gl_info, textype); + break; > > - upload_palette(surface, context); - break; > + default: + shader = > gen_yuv_shader(priv, gl_info, fixup, textype); + > break; + } > > - default: + if (!shader) + { > FIXME("Unsupported complex fixup %#x, not setting a shader\n", > fixup); gl_info->gl_ops.gl.p_glEnable(textype); > checkGLcall("glEnable(textype)"); return E_NOTIMPL; + } } - > - if (!shader) shader = gen_yuv_shader(priv, gl_info, fixup, > textype); + if (fixup == COMPLEX_FIXUP_P8) + > upload_palette(surface, context); > > gl_info->gl_ops.gl.p_glEnable(GL_FRAGMENT_PROGRAM_ARB); > checkGLcall("glEnable(GL_FRAGMENT_PROGRAM_ARB)"); > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS/MUJAAoJEN0/YqbEcdMwJDEQAIEBkWRt2YIly+I+2jO2Y2al MxewjsCeQRf2uFnn4QIVNSfBOrjx6tq5d4aaj0pMlW2O98nXpVJWrHH5suqdX3IP F57tC6bLkucvwuutKFn+h5JohkHw7mjiPjDMYV2H2Lml3Yy0CXDfpSUJsREfTXgl YefKfzxIjckRV/u64kCTOxXCjkeI1LakEWIs8zL8QKXHSUIQtUHfN5uNynbhSnNq SU7+d3B/p/ZFvdOpT6HyhXHyGmx584CcmDTIz9tj6JG0oWmHE6dLZoIrgR/f32iH M0SYfxFEpRhv26a3NFEx98VAHTarZKkMTrcu6QQIgZ0RiC1jpSOvidk98sIK7dbr T+ynOho0GaZt5ZC0pvc1w6GPw7sf040Oz2JcSqIxDX+S5JjqG7PsMvJSYcziY8xJ eBrYgpO/Db5DVyOHfEuFbcS6fyLcO9P9hi2VvhQx2TR9q2XQEMklMamo+OTGng5t cx61mfvCLUF/BsQBteW/SAIHaUGfKgUOgmPIJpucssVbULVXnxI1op1PcczvT6JP xqaG+GiXzuDMulcQR+gnYz7oWnMWj2AA+bPVrTKUhZTbEupUgG9j8CsxeJ678tlk bBKK1p/3UBz1+oc7Qo+Yu6mBVSjPSxwczxmErWe+L7K1kP2L8vtqYg06CSTPH8t7 Y6kf6yuWGIbyapYMcuAO =jA/i -----END PGP SIGNATURE-----

Feb. 13, 2014

Fixing up the code style

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, After recently helping two contributors (the Pipelight guys and Martin Storsjö) through the maze of the Wine code style I think it's best to lift the ban against style-only patches and unify the code style once and for all. The basic reasoning is that from my point of view the lack of clarity wrt the code style and lack of automatic enforceability is causing more issues than the problems style-only patches cause with git blame. Finding a style-only change with git blame can be handled by running git blame again. Frustrating contributors on the other hand has no workaround. So I propose to agree on a code style for the entire project, fixing it up preferably with an automated tool and in the future enforcing the style with checks in the Testbot. Opinions? Wrt the code style I propose the style that is used in wineserver. It is the same one as the new style in the d3d code except for single-line if conditions. Cheers, Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIbBAEBAgAGBQJS/MQGAAoJEN0/YqbEcdMw7rMP+LAP5pnxyy9onITtJVe8swuy pKrS+U1NgLIru9yGuuxUsejUr8gY9hD27nSQQ2OddzSV3pEkY6vmqftSIFVT8Oli d0kEXbxZhlzRe9rCgEJGLGx73ap/LBOm0k3jtslOVONlIyH8AXdEG37a2P7s8SKV D9p0Sw7ggNRF8D0eIszSPKjfUfBYph+9XU1SDA9aEfokv6rs6AFt9xehCOUsdayZ gwqiigg70tkez81GhDRfuXWVn6pdsVpeLDjxF4P2XFMT00OInJIYBIy2w91sxgOs 3vos4X60+qg+sIGxAhxgfLilVQSbBOqvBz9QEUycOduzJK87sVfGtpsipCX4qW1Z QNE+SOINHjazNPB0mydO7s6rThOuZS2BU5nG+ZaXmbe5RBUXLMqqjUmIGL2ZYodJ zQ+3eOHC0H8fxaNhqwpRh5Gq8fVE+xcXauovLv0Ro+FskOitfazIBJEfktjJuXZ8 YZcmLqQAGCwd0Y9pTOTXldoR9ah1+gO7ya5n2ljR0+viAol6KQoUaD4dFNhEur4j cpmW2EDks/wPVrvjX2u8cphHGeOLSjDEErnE/PoX5w7jNarekRWSSalanYB+04SX rjxUXSVq30upNdJ07W2L8gLaHTgHq0rglR1ZrSYEDw5FtaG/Xs4W0YqyX5APl/+O Bj4qRaV70TNOicRNgaA= =DQdS -----END PGP SIGNATURE-----

Feb. 13, 2014

Converting source to unicode, bug 28189

by Hugh McMaster

I've put together a draft patch to address bug 28189, regsvr32: No usage in wineconsole. I'm using resource strings and have converted all of the printf calls to WriteConsoleW. I also converted the source to Unicode, but overall, there are few coding points I'm not quite sure about. If someone could look over the changes and offer some feedback, I'd certainly appreciate it. URL: http://bugs.winehq.org/show_bug.cgi?id=28189 -- Hugh

Feb. 13, 2014