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

Re: [PATCH 2/3] d3dx9: Return D3DERR_INVALIDCALL in D3DXLoadSurfaceFromMemory if pDestRect is invalid
by Henri Verbeet July 26, 2010

July 26, 2010

2010/7/25 <tony.wasserka(a)freenet.de>: > + if(pDestRect->left > pDestRect->right || pDestRect->top > pDestRect->bottom) return D3DERR_INVALIDCALL; > + if(pDestRect->left > surfdesc.Width || pDestRect->right > surfdesc.Width) return D3DERR_INVALIDCALL; If left <= right <= Width, left can never be > Width.

1 0

Re: [PATCH 1/3] d3dx9: Move pixel sampling and recombination in copy_simple_data to separate helper functions
by Henri Verbeet July 26, 2010

July 26, 2010

On 25 July 2010 19:15, <tony.wasserka(a)freenet.de> wrote: > +typedef struct > { > + CONST PixelFormatDesc *srcformat; > + CONST PixelFormatDesc *destformat; > DWORD srcshift[4], destshift[4]; > DWORD srcmask[4], destmask[4]; > BOOL process_channel[4]; > - DWORD channels[4]; > - DWORD channelmask = 0; > + DWORD channelmask; > +} ARGB_CONVERSION_INFO; Please don't do that.

1 0

d3dx9: general direction/goal - speed, code "prettiness", etc?
by Misha Koshelev July 26, 2010

July 26, 2010

Dear All: Given my recent work on this bug: http://bugs.winehq.org/show_bug.cgi?id=22918 and on D3DXCreateSphere, with the latest iteration being: http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html I have been giving quite a bit of thought to d3dx9 and to mesh creation functions in particular. I have realized there is no "perfect" sphere creation function. Rather, there are functions that may be optimized for different purposes. Thus, I thought I'd pose the question - as to d3dx9, is our goal: a) speed b) code "prettiness" c) something else? I am tempted to think it is (a), but wanted to double check. For example, I have taken a look, per Henri's suggestion (wrt teapot), at freeglut 2.6.0 sources. For your reference: > freeglut is released under the X-Consortium license. Per http://www.winehq.org/pipermail/wine-devel/2010-July/085266.html, I believe it is okay to look at this code. In fact, the license looks strikingly like the one in: http://source.winehq.org/git/wine.git/?a=blob;f=dlls/gdi32/region.c#l26 with X Consortium changed to Pawel W. Olstza (?) In any case, I have taken the liberty of copying and pasting glutSolidSphere to the top of the attached file. As you can see, it is implemented in terms of triangle fans and quad strips. (You will notice, btw, the use of lookup tables - fghCircleTable - for cos and sin, which reinforces my belief that speed is our top interest in terms of a graphics library). Now you will note, my current D3DXCreateSphere patch: http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html creates unique vertices and indices (creating indices on a per-vertex basis per Henri's suggestion). I admit, this may not "look" as pretty as having triangle fans and quad strips. In fact, of course on possibility is to: a) create helper functions that make triangle fans and quad strips - because we are dealing with (unique) vertex buffers and index buffers for our (triangular) faces, we will need additional floating point comparison calls in each function to make sure that our vertices are unique b) use code a la freeglut to generate our vertex and index buffers Now this code might be a little "prettier" to look at, but I see some serious problems with this approach and would appreciate your comments/feedback. Here are some issues: i) KISS (keep it simple .. umm .. silly) - although not a computer scientist by formal training, I know well enough that in any system, the more complex the system, the more opportunities for random behavior. In other words, bugs. Clearly, this is why we have conformance tests. But it seems like it would be overkill to have conformance tests for helper functions, especially helper functions used in a test. ii) Most importantly - this would add at least three floating point comparisons per vertex that we add. This may not seem like a lot - until you start thinking of a sphere with, say, 1000 vertices (not too much for a spherical-looking sphere), and, say, for a game that generates 100 spheres. This means 100 x 1000 x 3 = 30000 extra floating point comparisons (which would involve a subtraction and comparison because we would be comparing to a predefined epsilon - not to mention the eternal question - which epsilon do we use?) Now this link is quite old: http://www.phoronix.com/scan.php?page=article&item=wine_feb08_tests&num=1 but surely Wine is constantly being benchmarked as far as graphics performance, since I believe one of the big uses of Wine currently is for games. Thus, it is reasonable that we do not want to take such a performance hit. In any case, this is my thought as to why http://www.winehq.org/pipermail/wine-patches/2010-July/091176.html is a good implementation for a sphere, rather than doing something more high level. And, in general, why we probably want to keep doing the vertex buffer/index buffer approach, and forgo an approach where we: (a) create non-unique vertices uses nice geometrical structures on the fly (triangle fans, quad strips) (b) generate vertex and index buffers from these on the fly. However, as always, feedback appreciated. Thank you and have a nice Saturday! Misha

2 4

Re: [3/3] msi/tests: Skip tests if UAC is enabled and the process is not running elevated.
by testbot＠testbot.winehq.org July 26, 2010

July 26, 2010

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=3902 Your paranoid android. === W7PROX64 (32 bit install) === install.c:3741: Test failed: Expected imaname, got ðõ install.c:3752: Test failed: Expected 314, got 12 install.c:3758: Test failed: Expected OrderTestValue, got ðõ === W7PROX64 (64 bit install) === install.c:10045: Test failed: key not removed install.c:10055: Test failed: key not removed install.c:10066: Test failed: key not removed install.c:10357: Test failed: key not created === W7PROX64 (32 bit package) === package.c:8371: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8382: Test failed: Expected "C:\winetest\", got "" package.c:8393: Test failed: Expected "C:\winetest\", got "" package.c:8443: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8454: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8463: Test failed: Expected "C:\", got "" package.c:8469: Test failed: Expected "C:\winetest\", got "" package.c:8490: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8499: Test failed: Expected "C:\winetest\FileName1", got "" === W7PROX64 (64 bit package) === package.c:8371: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8382: Test failed: Expected "C:\winetest\", got "" package.c:8393: Test failed: Expected "C:\winetest\", got "" package.c:8443: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8454: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8463: Test failed: Expected "C:\", got "" package.c:8469: Test failed: Expected "C:\winetest\", got "" package.c:8490: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8499: Test failed: Expected "C:\winetest\FileName1", got ""

1 0

Re: [PATCH 3/5] shell32: Initial implementation of IShellItemArray with SHCreateShellItemArray.
by Alexandre Julliard July 26, 2010

July 26, 2010

David Hedberg <david.hedberg(a)gmail.com> writes: > --- > dlls/shell32/Makefile.in | 1 + > dlls/shell32/shell32.spec | 1 + > dlls/shell32/shellitemarray.c | 270 ++++++++++++++++++++++++++++++++++++++++ > dlls/shell32/tests/shlfolder.c | 132 +++++++++++++++++++ > include/shobjidl.idl | 1 + > 5 files changed, 405 insertions(+), 0 deletions(-) > create mode 100644 dlls/shell32/shellitemarray.c > > diff --git a/dlls/shell32/Makefile.in b/dlls/shell32/Makefile.in > index 3099de2..3db4bdb 100644 > --- a/dlls/shell32/Makefile.in > +++ b/dlls/shell32/Makefile.in > @@ -31,6 +31,7 @@ C_SRCS = \ > regsvr.c \ > shell32_main.c \ > shellitem.c \ > + shellitemarray.c \ > shelllink.c \ > shellole.c \ > shellord.c \ This could go into shellitem.c, no need for a separate file. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/7] msvcp90/tests: Added allocator<char> tests (try2)
by Alexandre Julliard July 26, 2010

July 26, 2010

Piotr Caban <piotr(a)codeweavers.com> writes: > @@ -22,6 +22,13 @@ > #include <winbase.h> > #include "wine/test.h" > > +#ifndef __i386__ > +/* Skip these tests for non x86 platforms */ > +START_TEST(misc) > +{ > +} > +#else There's no reason not to run the tests on 64-bit, as long as the functions exist there, they should be tested too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/4] propsys/tests: Add tests for PSStringFromPropertyKey.
by testbot＠testbot.winehq.org July 26, 2010

July 26, 2010

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=3892 Your paranoid android. === WINEBUILD (build) === Make failed

2 1

Re: [4/4] propsys/tests: Add tests for PSPropertyKeyFromString.
by testbot＠testbot.winehq.org July 26, 2010

July 26, 2010

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=3893 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: propsys: add stub for PSPropertyKeyFromString
by Andrew Nguyen July 26, 2010

July 26, 2010

On Sun, Jul 25, 2010 at 2:09 PM, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > fixes http://bugs.winehq.org/show_bug.cgi?id=23528 > I don't mean to step on this patch, but I've sent a fuller implementation of PSPropertyKeyFromString which, if accepted, should take precedence over this stub.

1 0

Re: [PATCH] dlls/ntdll/file.c: Setting FileAllInformation is not 'fixable'.
by Nikolay Sivov July 25, 2010

July 25, 2010

On 7/24/2010 18:51, Max TenEyck Woodbury wrote: > --- > dlls/ntdll/file.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/dlls/ntdll/file.c b/dlls/ntdll/file.c > index 0a6ee55..86c200f 100644 > --- a/dlls/ntdll/file.c > +++ b/dlls/ntdll/file.c > @@ -2148,6 +2148,11 @@ NTSTATUS WINAPI NtSetInformationFile(HANDLE handle, PIO_STATUS_BLOCK io, > io->u.Status = STATUS_INVALID_PARAMETER_3; > break; > > + /* Invalid requests - do not need 'fixing'. */ > + case FileAllInformation: > + io->u.Status = STATUS_NOT_IMPLEMENTED; > + break; > + > default: > FIXME("Unsupported class (%d)\n", class); > io->u.Status = STATUS_NOT_IMPLEMENTED; Add a test please, and a comment won't be needed with a test too.

4 5