Re: d3dx9_36 [try 3]: Add a few tests for D3DXCreateBox
Most of the objections from the previous try still stand: check your whitespaces (whitespace after every comma, whitespaces around operators, whitespace after if or for keywords), you have to be consistent. Comparing indices doesn't make much sense now that you don't check vertices, I think you should drop that too. You could probably instead check for min and max x, y and z vertices coordinates, verifying that the box has the expected dimensions.
Re: wineport: Add support for ctz().
Adam Martinson amartin...@codeweavers.com writes:
@@ -239,6 +243,19 @@ extern int getopt_long_only (int ___argc, char *const
*___argv,
int ffs( int x );
#endif
+#if defined(__GNUC__) (GCC_VERSION = 30406)
+#define ctz(x) __builtin_ctz(x)
+#elif defined(__GNUC__) (defined(__i386__) || defined(__x86_64__))
+static inline int ctz( unsigned int x )
+{
+int ret;
+__asm__(bsfl %1, %0 : =r (ret) : r (x));
+return ret;
+}
+#else
+#define ctz(x) (ffs(x)-1)
+#endif
There's no reason to add this. Just use ffs().
--
Alexandre Julliard
julli...@winehq.org
Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)
Adam Martinson amartin...@codeweavers.com writes: --- dlls/wined3d/device.c | 17 - 1 files changed, 8 insertions(+), 9 deletions(-) You still need to demonstrate that this is an improvement. Compilers are pretty good nowadays, and doing such micro-optimizations at the source level is usually futile. -- Alexandre Julliard julli...@winehq.org
Re: mshtml, shdocvw: Initialize OLEINPLACEFRAMEINFO.cb for IOleInPlaceSite::GetWindowContext
Hi Thomas, On 3/16/11 11:21 AM, Thomas Faber wrote: Hi, the documentation for the OLEINPLACEFRAMEINFO structure [1] says that the 'cb' member must be initialized before passing the structure to IOleInPlaceSite::GetWindowContext (where the rest of it will be filled). In addition to the fix, I have updated the corresponding tests to check this member instead of setting it, and they pass on Windows as expected [2]. I've used a= compare for future version compatibility. Comparing to the exact value is better in this case. If the value will ever change, we want to know that and tests failures will help us notice it. Jacek
Re: Wine Gecko 1.2.0 released
On 3/15/11 10:44 PM, Scott Ritchie wrote: Do you really mean 1.3.15 or do you mean the upcoming 1.3.16? I meant post-1.3.15, so it's the updcoming 1.3.16, sorry for the confusion. Jacek
winmm DriverCallback with 0 CALLBACK_WINDOW
Hi, Testbot job #9994 proves that Wine and native differ in their handling of a 0 CALLBACK_WINDOW handle. Wine's PostMessage redirects a 0 handle to PostThreadMessage(currentThreadID()), while native finds no notification on the thread's queue in such a case. (As a consequence, Wine's player thread will send notification messages to itself ...) Alas, the test case does not allow to tell whether the difference in with - winmm:DriverCallback or - whether winmm:midiOutOpen sees the 0 handle and remap to CALLBACK_NULL internally, before ever calling DriverCallback. Likewise, a NULL CALLBACK_FUNCTION does not cause a crash since w2k, but we don't know whether winmm:DriverCallback catches that case (as Wine does nowadays) or whether winmm:wave/midi/mixer/Open remap that to maybe CALLBACK_NULL and proceed. Is there any means to tell the difference, short of writing a real driver with debug output and installing it on a native system, having native DriverCallback called directly? Any ideas? Jörg Höhle BTW, why does winealsa.drv:mixer use a custom callback mechanism instead of the generic DriverCallback that the other winmm drivers use? Historical reasons only?
lifetime of the MIDI/MIXER/WAVEOPENDESC structure?
Hi, MSDN is silent about the lifetime of the MIDI/MIXER/WAVEOPENDESC structure that is deliverred via the W/MODM_OPEN/MXM_OPEN message to the winmm drivers (WAVEOOPENDESC is not even documented for MS-Windows (not CE) anymore). http://msdn.microsoft.com/en-us/library/ff537518%28v=vs.85%29.aspx MIDIOPENDESC IMHO, it would make a lot of sense if the structure remained allocated for the whole lifetime of the open/close cycle, so the driver need not make a copy of it. Is there anybody who knows more about this topic? Thank you, Jörg Höhle
Re: kernel32: Implement and test GetVolumePathNamesForVolumeName. (try 2)
Hans Leidekker h...@codeweavers.com writes:
+for (i = 0; i output-NumberOfMountPoints; i++)
+{
+if (output-MountPoints[i].DeviceNameOffset)
+{
+const WCHAR *device = (const WCHAR *)((const char *)output +
output-MountPoints[i].DeviceNameOffset);
+UINT device_len = output-MountPoints[i].DeviceNameLength /
sizeof(WCHAR);
+int drive = map_dos_device( device, device_len );
+
+if (drive != -1)
+{
+len += 4;
+if (volumepathname len buflen)
+{
+path[0] = 'A' + drive;
+path[1] = ':';
+path[2] = '\\';
+path[3] = 0;
+path += 4;
+}
+}
+}
This won't allow you to support GUID volume names. I think you should
query all mount points that match the device, not just the DOS drives.
Either way you should use MOUNTMGR_QUERY_POINTS instead of trying every
drive one by one.
--
Alexandre Julliard
julli...@winehq.org
Re: windowscodecs: DibDecoder_CreateInstance() is unused so remove it.
I think this will be needed by d3dx9, though it hasn't been fully wired up yet.
Re: d3dx9_36/tests: Replace a malloc() with HeapAlloc()+HeapFree().
On Wed, Mar 16, 2011 at 3:57 AM, Francois Gouget fgou...@free.fr wrote: Any reason why we were not freeing glyphmetrics_float? No reason, just a mistake on my part.
Re: lifetime of the MIDI/MIXER/WAVEOPENDESC structure?
Hey, Op 16-03-11 16:03, joerg-cyril.hoe...@t-systems.com schreef: Hi, MSDN is silent about the lifetime of the MIDI/MIXER/WAVEOPENDESC structure that is deliverred via the W/MODM_OPEN/MXM_OPEN message to the winmm drivers (WAVEOOPENDESC is not even documented for MS-Windows (not CE) anymore). http://msdn.microsoft.com/en-us/library/ff537518%28v=vs.85%29.aspx MIDIOPENDESC IMHO, it would make a lot of sense if the structure remained allocated for the whole lifetime of the open/close cycle, so the driver need not make a copy of it. Is there anybody who knows more about this topic? I wouldn't count on it, the structure is allocated on the stack, see for example winmm.c: WAVE_Open Cheers, Maarten
Re: winmm DriverCallback with 0 CALLBACK_WINDOW
Hey, Op 16-03-11 15:52, joerg-cyril.hoe...@t-systems.com schreef: Hi, Testbot job #9994 proves that Wine and native differ in their handling of a 0 CALLBACK_WINDOW handle. Wine's PostMessage redirects a 0 handle to PostThreadMessage(currentThreadID()), while native finds no notification on the thread's queue in such a case. (As a consequence, Wine's player thread will send notification messages to itself ...) Considering PostThreadMessage(NULL) is supposed to post to the thread queue this is fine, feel free to fix though. Alas, the test case does not allow to tell whether the difference in with - winmm:DriverCallback or - whether winmm:midiOutOpen sees the 0 handle and remap to CALLBACK_NULL internally, before ever calling DriverCallback. Likewise, a NULL CALLBACK_FUNCTION does not cause a crash since w2k, but we don't know whether winmm:DriverCallback catches that case (as Wine does nowadays) or whether winmm:wave/midi/mixer/Open remap that to maybe CALLBACK_NULL and proceed. Is there any means to tell the difference, short of writing a real driver with debug output and installing it on a native system, having native DriverCallback called directly? In that case I wouldn't worry about it, just handle it in DriverCallback to save on duplication. BTW, why does winealsa.drv:mixer use a custom callback mechanism instead of the generic DriverCallback that the other winmm drivers use? Historical reasons only? I honestly can't remember. Probably because I only checked with sndvol32, feel free to send in a patch for it though. Cheers, Maarten
re: kernel32: CreateProcessA should not call CreateProcessW directly
Does that work when compiling with -O3 ? Maybe you need a noinline attribute, http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes
Re: kernel32: CreateProcessA should not call CreateProcessW directly
Hi Dan, Op 16-03-11 20:06, Dan Kegel schreef: Does that work when compiling with -O3 ? Maybe you need a noinline attribute, http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes I don't think it will ever be inlined because of the calling convention differences. Doing a dumb -O3 to be sure confirms it. Cheers, Maarten.
Re: wined3d/device: Avoid repeated calculations of idx and shift in IWineD3DDeviceImpl_MarkStateDirty(). (resend)
Adam Martinson amartin...@codeweavers.com writes: On 03/16/2011 02:24 PM, Alexandre Julliard wrote: Adam Martinsonamartin...@codeweavers.com writes: Look at any d3d app with oprofile. That function is called EVERYWHERE. In my testing this reduces IWineD3DDeviceImpl_MarkStateDirty() from 4.8% of wined3d CPU time to 3.3%. What compiler are you using? I don't see any difference here. GCC 4.4.5, running the 3DMark06 batch size tests. I don't see any difference with 4.4.5 either, the generated code is basically identical. If gcc really doesn't notice the loop invariant for you, something is wrong with your setup. -- Alexandre Julliard julli...@winehq.org
Re: mshtml,shdocvw: Initialize OLEINPLACEFRAMEINFO.cb for IOleInPlaceSite::GetWindowContext (try 2)
Thomas Faber thfa...@gmx.de wrote: ip_frame = NULL; ip_uiwindow = NULL; +frame_info.cb = sizeof(OLEINPLACEFRAMEINFO); Using sizeof(frame_info) here and in other places instead of sizeof(OLEINPLACEFRAMEINFO) would be better IMHO. -- Dmitry.
