Vacation
Hi folks, Once again you'll have to live without commits for a while, I'm off skiing for a week... -- Alexandre Julliard [EMAIL PROTECTED]
Re: gdiplus: bezier test question
On 25/01/2008, Dmitry Timoshkov [EMAIL PROTECTED] wrote:
Reece Dunn [EMAIL PROTECTED] wrote:
The patch that I have just submitted (gdiplus: fix the bezier arc
path test (on all platforms).) is a simple fix for the failing test
in graphicspath.c. The failure highlights gdiplus behaviour that is
not directly obvious:
If you have a bezier arc:
static path_test_t arc_path[] = {
{600.0, 450.0, PathPointTypeStart, 0, 0}, /*0*/
{600.0, 643.3, PathPointTypeBezier, 0, 0}, /*1*/
{488.1, 800.0, PathPointTypeBezier, 0, 0}, /*2*/
};
the gdiplus code will make the last entry PathPointTypeBezier |
PathPointTypeCloseSubpath.
For the nature of the existing test, I believe the fix is correct (it
is testing the basic arc path functionality). However, there should be
another test to document the above behaviour.
This behaviour matches what GDI32 does with adding PT_CLOSEFIGURE.
Looking into the test a bit more, it is calling GdipAddPathArc to
construct the path, and then ok_path is extracting the path data,
checking that data against the exprected data.
- Reece
ddraw: ddrawmodes test failures (all platforms)
Hi, Looking at the ddrawmode test failures, they are because the test is checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate is not 0. However, on many of the test platforms at http://test.winehq.org/data/200801161000, they are reporting a refresh rate of 0. Are these bogus - due to them running on VM - or is this a valid case? I don't currently have the ability to build those tests locally, so I cannot verify those failures. - Reece
Re: ddraw: ddrawmodes test failures (all platforms)
Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: Hi, Looking at the ddrawmode test failures, they are because the test is checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate is not 0. However, on many of the test platforms at http://test.winehq.org/data/200801161000, they are reporting a refresh rate of 0. Are these bogus - due to them running on VM - or is this a valid case? I don't currently have the ability to build those tests locally, so I cannot verify those failures. I have never seen such failures on my real hardware(Windows XP or Vista), so I think they fail due to VM drivers. I'll re-run the tests to make sure the tests didn't break somewhen.
Re: ddraw: ddrawmodes test failures (all platforms)
Am 01/26/2008 12:50 PM schrieb Stefan Dösinger: Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: Hi, Looking at the ddrawmode test failures, they are because the test is checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate is not 0. However, on many of the test platforms at http://test.winehq.org/data/200801161000, they are reporting a refresh rate of 0. Are these bogus - due to them running on VM - or is this a valid case? I don't currently have the ability to build those tests locally, so I cannot verify those failures. I have never seen such failures on my real hardware(Windows XP or Vista), so I think they fail due to VM drivers. I'll re-run the tests to make sure the tests didn't break somewhen. I don't think so. My system (called xanlosch) is a real XP system with an ATI Mobility 9700 graphic card with one of the latest ATI drivers (7.11er catalyst drivers). Maybe an ATI driver issue? Regards, Henning Gerhardt
Re: ddraw: ddrawmodes test failures (all platforms)
Am Samstag, 26. Januar 2008 13:20:44 schrieb Henning Gerhardt: Am 01/26/2008 12:50 PM schrieb Stefan Dösinger: Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: Hi, Looking at the ddrawmode test failures, they are because the test is checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate is not 0. However, on many of the test platforms at http://test.winehq.org/data/200801161000, they are reporting a refresh rate of 0. Are these bogus - due to them running on VM - or is this a valid case? I don't currently have the ability to build those tests locally, so I cannot verify those failures. I have never seen such failures on my real hardware(Windows XP or Vista), so I think they fail due to VM drivers. I'll re-run the tests to make sure the tests didn't break somewhen. I don't think so. My system (called xanlosch) is a real XP system with an ATI Mobility 9700 graphic card with one of the latest ATI drivers (7.11er catalyst drivers). Maybe an ATI driver issue? If the ATI driver behaves that way then I think our tests should accept this behavior I have a radeon 9000 mobility, and I don't remember any test failures
Re: ddraw: ddrawmodes test failures (all platforms)
Stefan Dösinger wrote: Am Samstag, 26. Januar 2008 13:20:44 schrieb Henning Gerhardt: Am 01/26/2008 12:50 PM schrieb Stefan Dösinger: Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn: Hi, Looking at the ddrawmode test failures, they are because the test is checking that if the DDSD_REFRESHRATE flag is set, then dwRefreshRate is not 0. However, on many of the test platforms at http://test.winehq.org/data/200801161000, they are reporting a refresh rate of 0. Are these bogus - due to them running on VM - or is this a valid case? I don't currently have the ability to build those tests locally, so I cannot verify those failures. I have never seen such failures on my real hardware(Windows XP or Vista), so I think they fail due to VM drivers. I'll re-run the tests to make sure the tests didn't break somewhen. I don't think so. My system (called xanlosch) is a real XP system with an ATI Mobility 9700 graphic card with one of the latest ATI drivers (7.11er catalyst drivers). Maybe an ATI driver issue? If the ATI driver behaves that way then I think our tests should accept this behavior I have a radeon 9000 mobility, and I don't remember any test failures Just ran the test on my real WinXP box (NVIDIA GeForce FX 5200) with the same results: http://test.winehq.org/data/200801161000/xp_XPSP2-HOME-NL/ddraw:ddrawmodes.txt -- Cheers, Paul.
d3dx8, d3dx9_xx and d3dx10_xx
Find attached some data on d3dx8, d3dx9_xx and d3dx10_xx implementations: dll files by d3dx extension: d3dx8 1 dll files d3dx9_xx 13 dll files d3dx10_xx 4 dll files Functions included in each d3dx: DLL Number of functions d3dx8 153 d3dx9_24 320 d3dx9_25 323 d3dx9_26 327 d3dx9_27 327 d3dx9_28 332 d3dx9_29 332 d3dx9_30 332 d3dx9_31 329 d3dx9_32 334 d3dx9_33 334 d3dx9_34 334 d3dx9_35 334 d3dx9_36 336 d3dx10_33 177 d3dx10_34 177 d3dx10_35 180 d3dx10_36 180 Total functions for all d3dx implementations: 5162 functions. Total functions for all d3dx implementations taking into account repetitions: 425 functions From these 425 functions: Functions specific to d3dx8: 15 Functions specific to d3dx9: 165 Functions specific to d3dx10: 71 Functions shared between d3dx8 and d3dx9: 65 Functions shared between d3dx9 and d3dx10: 35 Functions shared between the three implementations: 74 On the other hand, considering individual dlls, 17 functions are only mentioned in one dll 3 functions are mentioned in 2 dlls 68 functions are mentioned in 4 dlls 2 functions are mentioned in 7 dlls 10 functions are mentioned in 9 dlls 5 functions are mentioned in 11 dlls 3 functions are mentioned in 12 dlls 149 functions are mentioned in 13 dlls 65 functions are mentioned in 14 dlls 29 functions are mentioned in 17 dlls 74 functions are mentioned in 18 dlls
user32: understanding the HiliteMenuItem failures (all platforms)... call for help
Hi,
I am currently looking at the user32: menu (HiliteMenuItem) test failures:
menu.c:1884: Test failed: HiliteMenuItem: Item 1 is not hilited
menu.c:1891: Test failed: HiliteMenuItem: Item 3 is not hilited
1. These are failing consistently on all platforms (see
http://test.winehq.org/data/200801161000 - you may need to search for
HiliteMenuItem to find the failures!).
2. It appears (backed up with tests in the attached patch) that the
API fails when the HWND parameter is NULL.
3. The tests are not comprehensive enough.
The patch I have attached here is still a work in progress:
1. I have not tested it on Wine - it is likely that this will require
todo_wine markers to make it run successfully.
2. The tests are still failing on Windows (both XP and Vista).
Here is where I get stuck. According to the MDSN documentation (which
is likely to be wrong) this appears to be correct.
Does anyone know how to get HiliteMenuItem to work?!
- Reece
From e607b6e4580099dd7bb244b55d7bad725a6bda5a Mon Sep 17 00:00:00 2001
From: Reece H. Dunn [EMAIL PROTECTED]
Date: Sat, 26 Jan 2008 15:29:22 +
Subject: [PATCH] user32: menu improve the HiliteMenuItem tests.
---
dlls/user32/tests/menu.c | 63 ++---
1 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/dlls/user32/tests/menu.c b/dlls/user32/tests/menu.c
index cb37ac0..e27b95c 100644
--- a/dlls/user32/tests/menu.c
+++ b/dlls/user32/tests/menu.c
@@ -1864,6 +1864,7 @@ static void test_menu_flags( void )
static void test_menu_hilitemenuitem( void )
{
HMENU hMenu, hPopupMenu;
+HWND hwnd;
hMenu = CreateMenu();
hPopupMenu = CreatePopupMenu();
@@ -1874,25 +1875,67 @@ static void test_menu_hilitemenuitem( void )
AppendMenu(hPopupMenu, MF_STRING, 102, Item 2);
AppendMenu(hPopupMenu, MF_STRING, 103, Item 3);
-HiliteMenuItem(NULL, hPopupMenu, 0, MF_HILITE);
-HiliteMenuItem(NULL, hPopupMenu, 1, MF_HILITE);
-HiliteMenuItem(NULL, hPopupMenu, 2, MF_HILITE);
-HiliteMenuItem(NULL, hPopupMenu, 1, MF_UNHILITE);
+hwnd = CreateWindowEx(0, MAKEINTATOM(atomMenuCheckClass), NULL,
+ WS_VISIBLE, CW_USEDEFAULT, CW_USEDEFAULT, 200, 200,
+ NULL, hMenu, NULL, NULL);
+ok(hwnd != NULL, CreateWindowEx failed with error %d\n, GetLastError());
+
+/* no window */
+
+SetLastError(0xdeadbeef);
+ok(!HiliteMenuItem(NULL, hPopupMenu, 0, MF_HILITE),
+ HiliteMenuItem: hilite state set\n);
+ok(GetLastError() == ERROR_INVALID_WINDOW_HANDLE,
+ HiliteMenuItem: expected ERROR_INVALID_WINDOW_HANDLE, got %d\n,
GetLastError());
+
+/* initial state -- not hilited */
+
+ok(!(GetMenuState(hPopupMenu, 0, MF_BYPOSITION) MF_HILITE),
+ HiliteMenuItem: Item 1 is hilited\n);
+
+/* not hilited -- don't change the hilited state */
+
+SetLastError(0xdeadbeef);
+ok(!HiliteMenuItem(hwnd, hPopupMenu, 0, MF_UNHILITE),
+ HiliteMenuItem: unhilite state set, got error %d\n, GetLastError());
+
+ok(!(GetMenuState(hPopupMenu, 0, MF_BYPOSITION) MF_HILITE),
+ HiliteMenuItem: Item 1 is hilited, got error %d\n, GetLastError());
+
+/* hilited */
+
+SetLastError(0xdeadbeef);
+ok(HiliteMenuItem(hwnd, hPopupMenu, 0, MF_HILITE),
+ HiliteMenuItem: hilite state not set, got error %d\n, GetLastError());
todo_wine
{
ok(GetMenuState(hPopupMenu, 0, MF_BYPOSITION) MF_HILITE,
- HiliteMenuItem: Item 1 is not hilited\n);
+ HiliteMenuItem: Item 1 is not hilited, got error %d\n, GetLastError());
}
-ok(!(GetMenuState(hPopupMenu, 1, MF_BYPOSITION) MF_HILITE),
- HiliteMenuItem: Item 2 is hilited\n);
+
+/* hilited -- don't change the hilited state */
+
+SetLastError(0xdeadbeef);
+ok(!HiliteMenuItem(hwnd, hPopupMenu, 0, MF_HILITE),
+ HiliteMenuItem: hilite state set, got error %d\n, GetLastError());
+
todo_wine
{
-ok(GetMenuState(hPopupMenu, 2, MF_BYPOSITION) MF_HILITE,
- HiliteMenuItem: Item 3 is not hilited\n);
+ok(GetMenuState(hPopupMenu, 0, MF_BYPOSITION) MF_HILITE,
+ HiliteMenuItem: Item 1 is not hilited, got error %d\n, GetLastError());
}
-DestroyMenu(hMenu);
+/* not hilited */
+
+SetLastError(0xdeadbeef);
+ok(HiliteMenuItem(hwnd, hPopupMenu, 0, MF_UNHILITE),
+ HiliteMenuItem: unhilite state not set, got error %d\n,
GetLastError());
+
+ok(!(GetMenuState(hPopupMenu, 0, MF_BYPOSITION) MF_HILITE),
+ HiliteMenuItem: Item 1 is hilited, got error %d\n, GetLastError());
+
+DestroyWindow(hwnd);
}
static void check_menu_items(HMENU hmenu, UINT checked_cmd, UINT checked_type,
--
1.5.3.5
Re: d3dx8, d3dx9_xx and d3dx10_xx
Find attached some data on d3dx8, d3dx9_xx and d3dx10_xx implementations: dll files by d3dx extension: d3dx8 1 dll files d3dx9_xx 13 dll files d3dx10_xx 4 dll files [...] Nice work, how did you get the data? Did you run Dependency Walker on each dll or is there a more practical way? I'm creating stub dlls at the moment and need to get the parameters for each function on MSDN which is very time consuming and am looking for a faster way. However, to add a little more data, my list of the differences between the d3dx9 dlls: from d3dx9_24 to d3dx9_25: + D3DXUVAtlasCreate + D3DXUVAtlasPack + D3DXUVAtlasPartition from d3dx9_25 to d3dx9_26: + D3DXComputeIMTFromPerTexelSignal + D3DXComputeIMTFromPerVertexSignal + D3DXComputeIMTFromSignal + D3DXComputeIMTFromTexture from d3dx9_26 to d3dx9_27: (no changes) from d3dx9_27 to d3dx9_28: + D3DXPreprocessShader + D3DXPreprocessShaderFromFileA + D3DXPreprocessShaderFromFileW + D3DXPreprocessShaderFromResourceA + D3DXPreprocessShaderFromResourceW from d3dx9_28 to d3dx9_30: (no changes) from d3dx9_30 to d3dx9_31: - D3DXCpuOptimizations - D3DXGetTargetDescByName - D3DXGetTargetDescByVersion from d3dx9_31 to d3dx9_32: + D3DXSHMultiply2 + D3DXSHMultiply3 + D3DXSHMultiply4 + D3DXSHMultiply5 + D3DXSHMultiply6 from d3dx9_32 to d3dx9_35: (no changes) from d3dx9_35 to d3dx9_36: + D3DXCreateFragmentLinkerEx + D3DXGetShaderConstantTableEx They of course match to your reported number of function, great job. PS: My d3dx9_24 patch is on its way, just need to prove that everything is correct
MinGW cross compiler rpms available
Updated cross compiler rpms are available here: http://mirzam.it.vu.nl/mingw/ I can build the full test suite from Wine 0.9.54 with these. -Hans
