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

Re: wined3d: Only update the sampler map when needed

by Henri Verbeet

On 26 July 2011 22:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > - if (state < gl_info->limits.fragment_samplers) > + if (state < gl_info->limits.combined_samplers) This looks like it should be a separate change. > + device->fixed_function_usage_map = 0xff; This looks questionable, it will cause unused textures to be loaded.

July 26, 2011

Re: comctl32: Remove dead increments (clang)

by Marcus Meissner

On Tue, Jul 26, 2011 at 09:15:57PM +0200, André Hentschel wrote: > --- > dlls/comctl32/propsheet.c | 1 - > dlls/comctl32/rebar.c | 2 -- > 2 files changed, 0 insertions(+), 3 deletions(-) > > diff --git a/dlls/comctl32/propsheet.c b/dlls/comctl32/propsheet.c > index f711399..3dd0713 100644 > --- a/dlls/comctl32/propsheet.c > +++ b/dlls/comctl32/propsheet.c > @@ -543,7 +543,6 @@ static BOOL PROPSHEET_CollectPageInfo(LPCPROPSHEETPAGEW lppsp, > /* Extract the caption */ > psInfo->proppage[index].pszText = p; > TRACE("Tab %d %s\n",index,debugstr_w( p )); > - p += lstrlenW( p ) + 1; > > if (dwFlags & PSP_USETITLE) > { > diff --git a/dlls/comctl32/rebar.c b/dlls/comctl32/rebar.c > index 99bde77..8d4e6f3 100644 > --- a/dlls/comctl32/rebar.c > +++ b/dlls/comctl32/rebar.c > @@ -1576,8 +1576,6 @@ REBAR_SizeToHeight(REBAR_INFO *infoPtr, int height) > iRow++; > } > } > - else > - extra -= REBAR_SizeChildrenToHeight(infoPtr, first_visible(infoPtr), infoPtr->uNumBands, extra / infoPtr->uNumRows, &fChanged); > > if (fChanged) > REBAR_Layout(infoPtr); REBAR_SizeChildrenToHeight might set fChanged here, or? Ciao, Marcus

July 26, 2011

Re: comctl32: Remove dead increments (clang)

by Reece Dunn

2011/7/26 André Hentschel <nerv(a)dawncrow.de>: > --- a/dlls/comctl32/rebar.c > +++ b/dlls/comctl32/rebar.c > @@ -1576,8 +1576,6 @@ REBAR_SizeToHeight(REBAR_INFO *infoPtr, int height) > iRow++; > } > } > - else > - extra -= REBAR_SizeChildrenToHeight(infoPtr, first_visible(infoPtr), infoPtr->uNumBands, extra / infoPtr->uNumRows, &fChanged); IIUC, this should not remove the |REBAR_SizeChildrenToHeight| call, only the |extra -=| bit as |REBAR_SizeChildrenToHeight| is updating the |infoPtr| output parameter. - Reece

July 26, 2011

Re: Updated Clang static analysis results / Valgrind update

by André Hentschel

Am 26.07.2011 01:17, schrieb Austin English: > On Sat, Jul 2, 2011 at 19:15, Austin English <austinenglish(a)gmail.com> wrote: >> Web space usage was getting a bit high, so I've uploaded a tarball to >> a file download service: >> http://www.sendspace.com/file/5hot36 >> >> austin(a)aw21 ~ $ sha1sum scan-build-2011-07-02.tar.bz2 >> ac3cb3920ef97641fff1f5376f8136cef01f15bf scan-build-2011-07-02.tar.bz2 >> >> to use, just extract and open in your favorite browser: >> $ firefox index.html >> >> this was run against Clang from svn: clang version 3.0 (trunk 134320) >> >> Please send me any false positives that you'd like me to report upstream. >> >> Cheers, >> Austin >> >> P.S. For those of you wanting Valgrind results, I'm currently hitting >> a nasty Valgrind bug, waiting on upstream to fix: >> https://bugs.kde.org/show_bug.cgi?id=275673 >> >> (Thanks to Andrew N for finding the faulty commit) > > Updated clang results, with: > clang version 3.0 (trunk 135936) and wine-1.3.25-52-g9d7d37f > > are at http://www.sendspace.com/file/x81pne > 77f1b2d0fdd8cb79d4caf20279b36dc047fcc325 scan-build-2011-07-25.tar.xz > > This gives 1815 warnings (previously had 1857). Again, if you see any > false positives, please let me know so that I can report them > upstream. > > For valgrind, see http://austinenglish.com/logs/valgrind/2011-07-25-10.19 > I've disabled a few tests, to workaround valgrind bug 275673. See > http://code.google.com/p/winezeug/source/diff?spec=svn2431&r=2431&format=si… > > I've got some more interesting stuff in the works, time permitting. > Keep tuned ;-). > > Cheers, > Austin > > in your actual valgrind logs there is quite much noise about at ??? (in /usr/lib/i386-linux-gnu/libfontconfig.so.1.4.4) what's that? -- Best Regards, André Hentschel

July 26, 2011

Re: d3d8/tests: make sure to use return values (LLVM/Clang)

by Stefan Dösinger

On Tuesday 26 July 2011 17:33:54 Jacek Caban wrote: > On 07/26/11 17:22, Henri Verbeet wrote: > > No, I disagree with the basic idea that stricter tests are necessarily > > better. The advantage of SUCCEEDED is that it's *less* strict. > > We won't agree on that. I prefer comparison against S_OK(or D3D_OK, which is just S_OK) for the ok() lines and SUCCEEDED/FAILED for figuring out control flow inside the tests. At least until a Windows version or driver returns a success value other than D3D_OK. But either way that's not a strong opinion. I am fine with either way, and I think I've used SUCCEEDED/FAILED myself for ok() statements mostly because Henri has used it and to keep the code consistent.

July 26, 2011

Re: d3d8/tests: make sure to use return values (LLVM/Clang)

by Jacek Caban

On 07/26/11 17:22, Henri Verbeet wrote: > On 26 July 2011 16:57, Jacek Caban <jacek(a)codeweavers.com> wrote: >> Seriously, I'm not talking about anything like that. We get to choose >> between using two things. SUCCEDEED() has no advantages over testing >> exact values in this context. Testing the exact value has a small, but >> still, advantage. I believe we agree on this. Then if you have a choice, > No, I disagree with the basic idea that stricter tests are necessarily > better. The advantage of SUCCEEDED is that it's *less* strict. We won't agree on that. > That said, the specific issue is insignificant enough that I wouldn't > care about e.g. a new test using "hr == D3D_OK". I just don't think > that changing existing tests from SUCCEEDED to "hr == D3D_OK" is > really an improvement. Well, I didn't say anything about changing existing code and I didn't even try to reject a patch because of that. I was commenting a new code that had to be resent to wine-patches anyway, so I don't know what was the discussion about... Cheers, Jacek

July 26, 2011

Re: d3d8/tests: make sure to use return values (LLVM/Clang)

by Henri Verbeet

On 26 July 2011 16:57, Jacek Caban <jacek(a)codeweavers.com> wrote: > Seriously, I'm not talking about anything like that. We get to choose > between using two things. SUCCEDEED() has no advantages over testing > exact values in this context. Testing the exact value has a small, but > still, advantage. I believe we agree on this. Then if you have a choice, No, I disagree with the basic idea that stricter tests are necessarily better. The advantage of SUCCEEDED is that it's *less* strict. That said, the specific issue is insignificant enough that I wouldn't care about e.g. a new test using "hr == D3D_OK". I just don't think that changing existing tests from SUCCEEDED to "hr == D3D_OK" is really an improvement.

July 26, 2011

Re: d3d8/tests: make sure to use return values (LLVM/Clang)

by Jacek Caban

On 07/26/11 16:34, Henri Verbeet wrote: > On 26 July 2011 16:08, Jacek Caban <jacek(a)codeweavers.com> wrote: >> If there is no cost of having tests more strict (like code >> complication), it is a good principle IMO. In this case it's a matter of >> choosing the right way for testing results, so it should be preferable. >> > We're not testing return codes here, so IMO we don't care about them > beyond detecting failures early. As a general principle though, the > point has always been to test behaviour that actual applications > depend on, not finding the most obscure implementation details of > native. Also, it's not unheard of for some of those details to change > between Windows versions. If applications don't care, we don't either. I'm sure apps *do* care about return codes. It's not like we're talking about an obscure failure corner cases. >>> (Not that it matters a lot here anyway, for most of these >>> D3D_OK is the only possible sucessful return value.) >> How can you be sure without tests? >> > Well, aside from disassembling the entire thing for every single > Windows version, you can't, even with tests. Yeah, but with tests I can be much more confident saying so. But first of all, I don't care about all versions and all corner cases, I care about the usual case. And that's something tests will show you easily. > I mean, native D3D could > do something obscure like switching all return codes to S_FALSE after > drawing a green icosahedron, but I think it's somewhat unlikely. Seriously, I'm not talking about anything like that. We get to choose between using two things. SUCCEDEED() has no advantages over testing exact values in this context. Testing the exact value has a small, but still, advantage. I believe we agree on this. Then if you have a choice, you choose the one that is slightly better, even if you don't care about this advantage in this particular case. Cheers, Jacek

July 26, 2011

Re: d3d8/tests: make sure to use return values (LLVM/Clang)

by Henri Verbeet

On 26 July 2011 16:08, Jacek Caban <jacek(a)codeweavers.com> wrote: > If there is no cost of having tests more strict (like code > complication), it is a good principle IMO. In this case it's a matter of > choosing the right way for testing results, so it should be preferable. > We're not testing return codes here, so IMO we don't care about them beyond detecting failures early. As a general principle though, the point has always been to test behaviour that actual applications depend on, not finding the most obscure implementation details of native. Also, it's not unheard of for some of those details to change between Windows versions. If applications don't care, we don't either. >> (Not that it matters a lot here anyway, for most of these >> D3D_OK is the only possible sucessful return value.) > > How can you be sure without tests? > Well, aside from disassembling the entire thing for every single Windows version, you can't, even with tests. I mean, native D3D could do something obscure like switching all return codes to S_FALSE after drawing a green icosahedron, but I think it's somewhat unlikely.

July 26, 2011

Re: d3d8/tests: make sure to use return values (LLVM/Clang)

by Jacek Caban

On 07/26/11 13:04, Henri Verbeet wrote: > On 26 July 2011 10:57, Jacek Caban <jacek(a)codeweavers.com> wrote: >> It's better to test for the exact value in tests like hr == S_OK. It >> makes tests stricter. > I don't think that making tests more strict than necessary is a good > principle. If there is no cost of having tests more strict (like code complication), it is a good principle IMO. In this case it's a matter of choosing the right way for testing results, so it should be preferable. > (Not that it matters a lot here anyway, for most of these > D3D_OK is the only possible sucessful return value.) How can you be sure without tests? Cheers, Jacek

July 26, 2011