Re: [PATCH] user32: Don't ignore return value of MapWindowPoints
On 10/16/2012 04:10, danielfsan...@att.net wrote:
ScreenToClient should return zero if the operation fails, but is always
returning TRUE. This patch corrects the problem and solves a crash bug
in Lord of the Rings Online (bug #31979)
Credit for this patch goes to some one else, as yet unidentified, since
it originally came from a closed forum for beta testers of the LoTRO
Riders of Rohan expansion and the forum has subsequently been wiped.
---
dlls/user32/winpos.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/dlls/user32/winpos.c b/dlls/user32/winpos.c
index 5a2f1f2..3855b19 100644
--- a/dlls/user32/winpos.c
+++ b/dlls/user32/winpos.c
@@ -250,8 +250,7 @@ BOOL WINAPI ClientToScreen( HWND hwnd, LPPOINT lppnt )
*/
BOOL WINAPI ScreenToClient( HWND hwnd, LPPOINT lppnt )
{
-MapWindowPoints( 0, hwnd, lppnt, 1 );
-return TRUE;
+return MapWindowPoints( 0, hwnd, lppnt, 1 ) != 0;
}
This needs a test.
Re: dwrite: Implement GetMetrics() for IDWriteFont
Nikolay Sivov nsi...@codeweavers.com wrote:
+static const WCHAR arialW[] = {'A','r','i','a','l',0};
Please don't use fonts which Wine doesn't provide. Testing Tahoma is fine.
--
Dmitry.
Re: dwrite: Implement GetMetrics() for IDWriteFont
On 10/16/2012 10:29, Dmitry Timoshkov wrote:
Nikolay Sivov nsi...@codeweavers.com wrote:
+static const WCHAR arialW[] = {'A','r','i','a','l',0};
Please don't use fonts which Wine doesn't provide. Testing Tahoma is fine.
Makes sense, thanks.
Re: ntdll: Don't use strncasecmp for _strnicmp implementation
On Tue, Oct 16, 2012 at 12:38:51PM +0200, Jacek Caban wrote:
---
dlls/ntdll/string.c | 12 +++-
dlls/ntdll/tests/string.c | 33 +
2 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/dlls/ntdll/string.c b/dlls/ntdll/string.c
index 716dbdf..288e910 100644
--- a/dlls/ntdll/string.c
+++ b/dlls/ntdll/string.c
@@ -254,7 +254,17 @@ int __cdecl _stricmp( LPCSTR str1, LPCSTR str2 )
*/
int __cdecl _strnicmp( LPCSTR str1, LPCSTR str2, size_t n )
{
-return strncasecmp( str1, str2, n );
+int ret = 0;
+
+/* 32-bit Windows return only -1,0,1 values */
+while(n--) {
+if(!*str1)
+return sizeof(void*) == 4 ? (*str2 ? -1 : 0) : -(unsigned
char)*str2;
+if((ret = tolower(*str1++) - tolower(*str2++)))
+return sizeof(void*) == 4 ? (ret 0 ? 1 : -1) : ret;
+}
Errm. Why not
int ret = strncasecmp( str1, str2, n );
if (ret 0 ) return -1;
if (ret 0 ) return 1;
return 0;
Ciao, Marcus
Re: ntdll: Don't use strncasecmp for _strnicmp implementation
On 10/16/12 13:08, Marcus Meissner wrote:
On Tue, Oct 16, 2012 at 12:38:51PM +0200, Jacek Caban wrote:
---
dlls/ntdll/string.c | 12 +++-
dlls/ntdll/tests/string.c | 33 +
2 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/dlls/ntdll/string.c b/dlls/ntdll/string.c
index 716dbdf..288e910 100644
--- a/dlls/ntdll/string.c
+++ b/dlls/ntdll/string.c
@@ -254,7 +254,17 @@ int __cdecl _stricmp( LPCSTR str1, LPCSTR str2 )
*/
int __cdecl _strnicmp( LPCSTR str1, LPCSTR str2, size_t n )
{
-return strncasecmp( str1, str2, n );
+int ret = 0;
+
+/* 32-bit Windows return only -1,0,1 values */
+while(n--) {
+if(!*str1)
+return sizeof(void*) == 4 ? (*str2 ? -1 : 0) : -(unsigned
char)*str2;
+if((ret = tolower(*str1++) - tolower(*str2++)))
+return sizeof(void*) == 4 ? (ret 0 ? 1 : -1) : ret;
+}
Errm. Why not
int ret = strncasecmp( str1, str2, n );
if (ret 0 ) return -1;
if (ret 0 ) return 1;
return 0;
That wasn't the original reason for writing this patch. It seems like
some distros (well, at least some Gentoo installations) have broken
strncasecmp.
Jacek
Re: ntdll: Don't use strncasecmp for _strnicmp implementation
On Tue, Oct 16, 2012 at 01:12:50PM +0200, Jacek Caban wrote:
On 10/16/12 13:08, Marcus Meissner wrote:
On Tue, Oct 16, 2012 at 12:38:51PM +0200, Jacek Caban wrote:
---
dlls/ntdll/string.c | 12 +++-
dlls/ntdll/tests/string.c | 33 +
2 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/dlls/ntdll/string.c b/dlls/ntdll/string.c
index 716dbdf..288e910 100644
--- a/dlls/ntdll/string.c
+++ b/dlls/ntdll/string.c
@@ -254,7 +254,17 @@ int __cdecl _stricmp( LPCSTR str1, LPCSTR str2 )
*/
int __cdecl _strnicmp( LPCSTR str1, LPCSTR str2, size_t n )
{
-return strncasecmp( str1, str2, n );
+int ret = 0;
+
+/* 32-bit Windows return only -1,0,1 values */
+while(n--) {
+if(!*str1)
+return sizeof(void*) == 4 ? (*str2 ? -1 : 0) : -(unsigned
char)*str2;
+if((ret = tolower(*str1++) - tolower(*str2++)))
+return sizeof(void*) == 4 ? (ret 0 ? 1 : -1) : ret;
+}
Errm. Why not
int ret = strncasecmp( str1, str2, n );
if (ret 0 ) return -1;
if (ret 0 ) return 1;
return 0;
That wasn't the original reason for writing this patch. It seems like
some distros (well, at least some Gentoo installations) have broken
strncasecmp.
How exactly? Do you know more details / urls?
Does it return -n ... +n values? Like the memcmp optimization that caused mysql
security issue?
In that case my patch should work.
Ciao, Marcus
Re: ntdll: Don't use strncasecmp for _strnicmp implementation
On 10/16/12 13:16, Marcus Meissner wrote:
On Tue, Oct 16, 2012 at 01:12:50PM +0200, Jacek Caban wrote:
On 10/16/12 13:08, Marcus Meissner wrote:
On Tue, Oct 16, 2012 at 12:38:51PM +0200, Jacek Caban wrote:
---
dlls/ntdll/string.c | 12 +++-
dlls/ntdll/tests/string.c | 33 +
2 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/dlls/ntdll/string.c b/dlls/ntdll/string.c
index 716dbdf..288e910 100644
--- a/dlls/ntdll/string.c
+++ b/dlls/ntdll/string.c
@@ -254,7 +254,17 @@ int __cdecl _stricmp( LPCSTR str1, LPCSTR str2 )
*/
int __cdecl _strnicmp( LPCSTR str1, LPCSTR str2, size_t n )
{
-return strncasecmp( str1, str2, n );
+int ret = 0;
+
+/* 32-bit Windows return only -1,0,1 values */
+while(n--) {
+if(!*str1)
+return sizeof(void*) == 4 ? (*str2 ? -1 : 0) : -(unsigned
char)*str2;
+if((ret = tolower(*str1++) - tolower(*str2++)))
+return sizeof(void*) == 4 ? (ret 0 ? 1 : -1) : ret;
+}
Errm. Why not
int ret = strncasecmp( str1, str2, n );
if (ret 0 ) return -1;
if (ret 0 ) return 1;
return 0;
That wasn't the original reason for writing this patch. It seems like
some distros (well, at least some Gentoo installations) have broken
strncasecmp.
How exactly? Do you know more details / urls?
Does it return -n ... +n values? Like the memcmp optimization that caused
mysql security issue?
In that case my patch should work.
From what I know following call crashes:
strncasecmp(, , 1);
It's probably a corner case for some optimizations.
Jacek
Re: ntdll: Don't use strncasecmp for _strnicmp implementation
Jacek Caban ja...@codeweavers.com writes: That wasn't the original reason for writing this patch. It seems like some distros (well, at least some Gentoo installations) have broken strncasecmp. There are many places in Wine that use strncasecmp, we don't want to change them all just because of some Gentoo screwup. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 7/8] mshtml: Added IHTMLScriptElement::put_src tests
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=22264 Your paranoid android. === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === TEST64_W7SP1 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found === TEST64_W7SP1 (64 bit) === No test summary line found
Re: [PATCH 2/6] d3dcompiler: Improve a Nvidia GPU recognition fallback.
Ehh, this patch should have been called something like wined3d: Improve a Nvidia GPU recognition fallback., but well...
Re: [PATCH] user32: Add tests showing that MapWindowPoints, ClientToScreen and ScreenToClient never fail.
On Tue, Oct 16, 2012 at 11:12 AM, Christian Costa titan.co...@gmail.com wrote: ... +wnd = CreateWindowA(static, NULL, 0, 0, 0, rect.right / 2, rect.bottom / 2, 0, 0, 0, 0); +//SetWindowPos(wnd, NULL, 0, 0, rect.right / 2, rect.bottom / 2, 0); Leftover debug code. Cheers, Austin
user32 tests patch
Forget my user32 patch. MapWindowPoints tests are wrong.
Re: [PATCH] user32: Add tests showing that MapWindowPoints, ClientToScreen and ScreenToClient never fail.
On 16 October 2012 20:12, Christian Costa titan.co...@gmail.com wrote: +//SetWindowPos(wnd, NULL, 0, 0, rect.right / 2, rect.bottom / 2, 0); C99 comment. I don't think these are very interesting cases though, it's probably more interesting what happens with e.g. a destroyed window, or a fullscreen window.
Re: programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Mac OS/X
Aric Stewart a...@codeweavers.com writes:
@@ -403,6 +404,13 @@ static HRESULT convert_to_native_icon(IStream *icoFile,
int *indices, int numInd
WINE_ERR(error 0x%08X creating IWICBitmapDecoder\n, hr);
goto end;
}
+#ifdef __APPLE__
+hr = IWICImagingFactory_CreateBitmapScaler(factory, scaler);
+if (FAILED(hr))
+{
+WINE_WARN(error 0x%08X creating IWICBitmapScaler\n, hr);
+}
+#endif
Please try to do that without adding #ifdefs in generic functions.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH] cmd: Properly handle multibyte characters in batch files.
Akihiro Sagawa sagawa@gmail.com writes:
@@ -244,7 +244,8 @@ WCHAR *WCMD_fgets(WCHAR *buf, DWORD noChars, HANDLE h)
if (!WCMD_is_console_handle(h) i != charsRead) {
/* Sets file pointer to the start of the next line, if any */
-filepos.QuadPart += i + 1 + (buf[i] == '\r' ? 1 : 0);
+INT bytes = WideCharToMultiByte(GetConsoleCP(), 0, buf, i, NULL, 0,
NULL, NULL);
+filepos.QuadPart += bytes + 1 + (buf[i] == '\r' ? 1 : 0);
There's no guarantee that all characters would round-trip properly, this
should be based on the original multibyte length somehow.
--
Alexandre Julliard
julli...@winehq.org
Re: programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Mac OS/X
I can but i feel like it would be more esoteric.
Something like if numIndices is greater than 1... Would that be more preferable?
-aric
On 10/16/12 1:39 PM, Alexandre Julliard wrote:
Aric Stewart a...@codeweavers.com writes:
@@ -403,6 +404,13 @@ static HRESULT convert_to_native_icon(IStream *icoFile,
int *indices, int numInd
WINE_ERR(error 0x%08X creating IWICBitmapDecoder\n, hr);
goto end;
}
+#ifdef __APPLE__
+hr = IWICImagingFactory_CreateBitmapScaler(factory, scaler);
+if (FAILED(hr))
+{
+WINE_WARN(error 0x%08X creating IWICBitmapScaler\n, hr);
+}
+#endif
Please try to do that without adding #ifdefs in generic functions.
Re: programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Mac OS/X
Aric Stewart a...@codeweavers.com writes: I can but i feel like it would be more esoteric. Something like if numIndices is greater than 1... Would that be more preferable? No, but there's no reason that icon scaling would be Mac-specific, it just needs a general mechanism for specifying destination size or something like that. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH] user32: Add tests showing that MapWindowPoints, ClientToScreen and ScreenToClient never fail.
On 16.10.2012 20:21, Henri Verbeet wrote:
On 16 October 2012 20:12, Christian Costa titan.co...@gmail.com wrote:
+//SetWindowPos(wnd, NULL, 0, 0, rect.right / 2, rect.bottom / 2, 0);
C99 comment.
I don't think these are very interesting cases though, it's probably
more interesting what happens with e.g. a destroyed window, or a
fullscreen window.
The interesting cases are likely:
ret = ScreenToClient(NULL, NULL);
ok(ret == FALSE, Failed\n);
/* invalid handle */
ret = ScreenToClient(0xdeadbeef, p);
ok(ret == FALSE, Failed\n);
p.x = p.y = 100;
ret = ScreenToClient(NULL, p);
ok(ret == FALSE, Failed\n);
ok(p.x == 100 p.y == 100, Failed\n);
p.x = p.y = 0;
ret = ScreenToClient(NULL, p);
ok(ret == FALSE, Failed\n);
ok(p.x == 0 p.y == 0, Failed\n);
/* create test window */
wnd = CreateWindow(static, test, 100, 200, 150, 150, 0, NULL,
NULL, NULL, NULL);
ret = ScreenToClient(wnd, NULL);
ok(ret == FALSE, Failed\n);
wnd = CreateWindowA(static, NULL, 0, 0, 0, rect.right / 2,
rect.bottom / 2, 0, 0, 0, 0);
p.x = p.y = 0;
ret = ScreenToClient(wnd, p);
ok(...);
ok(...);
And the implementation:
BOOL WINAPI ScreenToClient( HWND hwnd, LPPOINT lppnt )
{
/* !hwnd is redundant, but faster, MapWindowPoints(0, 0, ...) will
return 0 */
if (!hwnd || !lppnt) return FALSE;
return MapWindowPoints( 0, hwnd, lppnt, 1 ) != 0;
}
If I remember correctly, the game passes some NULL hwnd and invalid hwnd in.
Cheers
Rico
Re: [PATCH] user32: Add tests showing that MapWindowPoints, ClientToScreen and ScreenToClient never fail.
Le 16/10/2012 20:15, Austin English a écrit : On Tue, Oct 16, 2012 at 11:12 AM, Christian Costa titan.co...@gmail.com wrote: ... +wnd = CreateWindowA(static, NULL, 0, 0, 0, rect.right / 2, rect.bottom / 2, 0, 0, 0, 0); +//SetWindowPos(wnd, NULL, 0, 0, rect.right / 2, rect.bottom / 2, 0); Leftover debug code. Cheers, Austin Oups. ;)
Re: [PATCH] user32: Add tests showing that MapWindowPoints, ClientToScreen and ScreenToClient never fail.
Le 16/10/2012 20:21, Henri Verbeet a écrit : On 16 October 2012 20:12, Christian Costa titan.co...@gmail.com wrote: +//SetWindowPos(wnd, NULL, 0, 0, rect.right / 2, rect.bottom / 2, 0); C99 comment. I don't think these are very interesting cases though, it's probably more interesting what happens with e.g. a destroyed window, or a fullscreen window. Do you mean invalid handle ?
Re: [PATCH] user32: Add tests showing that MapWindowPoints, ClientToScreen and ScreenToClient never fail.
Le 16/10/2012 21:31, Rico Schüller a écrit :
On 16.10.2012 20:21, Henri Verbeet wrote:
On 16 October 2012 20:12, Christian Costa titan.co...@gmail.com wrote:
+//SetWindowPos(wnd, NULL, 0, 0, rect.right / 2, rect.bottom /
2, 0);
C99 comment.
I don't think these are very interesting cases though, it's probably
more interesting what happens with e.g. a destroyed window, or a
fullscreen window.
The interesting cases are likely:
ret = ScreenToClient(NULL, NULL);
ok(ret == FALSE, Failed\n);
/* invalid handle */
ret = ScreenToClient(0xdeadbeef, p);
ok(ret == FALSE, Failed\n);
p.x = p.y = 100;
ret = ScreenToClient(NULL, p);
ok(ret == FALSE, Failed\n);
ok(p.x == 100 p.y == 100, Failed\n);
p.x = p.y = 0;
ret = ScreenToClient(NULL, p);
ok(ret == FALSE, Failed\n);
ok(p.x == 0 p.y == 0, Failed\n);
/* create test window */
wnd = CreateWindow(static, test, 100, 200, 150, 150, 0, NULL,
NULL, NULL, NULL);
ret = ScreenToClient(wnd, NULL);
ok(ret == FALSE, Failed\n);
wnd = CreateWindowA(static, NULL, 0, 0, 0, rect.right / 2,
rect.bottom / 2, 0, 0, 0, 0);
p.x = p.y = 0;
ret = ScreenToClient(wnd, p);
ok(...);
ok(...);
And the implementation:
BOOL WINAPI ScreenToClient( HWND hwnd, LPPOINT lppnt )
{
/* !hwnd is redundant, but faster, MapWindowPoints(0, 0, ...) will
return 0 */
if (!hwnd || !lppnt) return FALSE;
return MapWindowPoints( 0, hwnd, lppnt, 1 ) != 0;
}
If I remember correctly, the game passes some NULL hwnd and invalid
hwnd in.
Cheers
Rico
Thanks. I will update the tests. Anyway I don't know how MapWindowPoint
could fail altough MSDN says to SetLastError before and check last error
to see if it failed.
Re: testbot/lib: If we cannot open the log file, then log to stderr.
On Mon, 15 Oct 2012, Christian Costa wrote: [...] Why not if I can make it run the test after the extraction. That said why not improving test bot download extra files? Is there a specific reason for that? I'm not against improving the testbot, it was just a suggestion. It's a good one.I will file a bug in bugzilla for the test bot and try your suggestion. Do you know any simple tool that enables to do that? If the sfx approach can be made to work without changes to WineTestBot then it may be worth documenting somewhere on the Wiki. Otherwise I'd rather modify WineestBot to accept .zip files in addition to .exe ones. This would cause the zip file to be extracted in a temporary directory, maybe not allowing subdirectories, and the one .exe file it contains would be run. I think that process would be more intuitive. If we need to allow more than one exe, letting the user specify the command to run should resolve any ambiguities. -- Francois Gouget fgou...@codeweavers.com
Re: [PATCH 5/5] ddraw/tests: Add some display mode set / restore tests with multiple ddraw objects.
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=22275 Your paranoid android. === WNT4WSSP6 (32 bit ddraw2) === ddraw2.c:2526: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2543: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2551: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2553: Test failed: Got unexpected screen width 800. ddraw2.c:2555: Test failed: Got unexpected screen height 600. ddraw2.c:2574: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2582: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2584: Test failed: Got unexpected screen width 800. ddraw2.c:2586: Test failed: Got unexpected screen height 600. ddraw2.c:2606: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2608: Test failed: Got unexpected screen width 800. ddraw2.c:2610: Test failed: Got unexpected screen height 600. ddraw2.c:2615: Test failed: Got unexpected screen width 800. ddraw2.c:2617: Test failed: Got unexpected screen height 600. ddraw2.c:2630: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2638: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw2.c:2640: Test failed: Got unexpected screen width 800. ddraw2.c:2642: Test failed: Got unexpected screen height 600. ddraw2.c:2650: Test failed: Got unexpected screen width 800. ddraw2.c:2652: Test failed: Got unexpected screen height 600. ddraw2.c:2664: Test failed: SetDipslayMode failed, hr 0x887600e1. === WNT4WSSP6 (32 bit ddraw1) === ddraw1.c:2389: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2406: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2414: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2416: Test failed: Got unexpected screen width 800. ddraw1.c:2418: Test failed: Got unexpected screen height 600. ddraw1.c:2437: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2445: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2447: Test failed: Got unexpected screen width 800. ddraw1.c:2449: Test failed: Got unexpected screen height 600. ddraw1.c:2469: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2471: Test failed: Got unexpected screen width 800. ddraw1.c:2473: Test failed: Got unexpected screen height 600. ddraw1.c:2478: Test failed: Got unexpected screen width 800. ddraw1.c:2480: Test failed: Got unexpected screen height 600. ddraw1.c:2493: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2501: Test failed: SetDipslayMode failed, hr 0x887600e1. ddraw1.c:2503: Test failed: Got unexpected screen width 800. ddraw1.c:2505: Test failed: Got unexpected screen height 600. ddraw1.c:2513: Test failed: Got unexpected screen width 800. ddraw1.c:2515: Test failed: Got unexpected screen height 600. ddraw1.c:2527: Test failed: SetDipslayMode failed, hr 0x887600e1.
Re: (resend) programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Icns format
On Oct 16, 2012, at 2:15 PM, Aric Stewart wrote: @@ -1052,6 +1079,7 @@ static inline int size_to_slot(int size) case 16: return 0; case 32: return 1; case 48: return 2; +case 64: return 2; /* Classic Mode */ case 128: return 3; case 256: return 4; case 512: return 5; If an ICO has both a 48x48 and a 64x64 entry (improbable, I know), then the 48x48 should be preferred. So, you need additional logic to pick the best index for a slot in platform_write_icon(). Track the best-so-far's width and prefer the smaller. Beyond that, perhaps the scaling should be put into the ICNS encoder rather than convert_to_native_icon(). That is, if it's handed a size that doesn't fit properly into one of the predefined slots, it would scale down to the next lower size. Although it might be better to synthesize a 32x32 rather than a 48x48 from a 64x64. *shrug* -Ken
Re: (resend) programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Icns format
On 10/16/12 7:40 PM, Ken Thomases wrote: On Oct 16, 2012, at 2:15 PM, Aric Stewart wrote: @@ -1052,6 +1079,7 @@ static inline int size_to_slot(int size) case 16: return 0; case 32: return 1; case 48: return 2; +case 64: return 2; /* Classic Mode */ case 128: return 3; case 256: return 4; case 512: return 5; If an ICO has both a 48x48 and a 64x64 entry (improbable, I know), then the 48x48 should be preferred. So, you need additional logic to pick the best index for a slot in platform_write_icon(). Track the best-so-far's width and prefer the smaller. I thought about that case and decided not to worry about it, however I will work out some logic to cover it. Beyond that, perhaps the scaling should be put into the ICNS encoder rather than convert_to_native_icon(). That is, if it's handed a size that doesn't fit properly into one of the predefined slots, it would scale down to the next lower size. I thought about this also and was not sure if the ICNS encoder in windowscodecs was following some spec or understood behavior on rejecting the size. I know that winemenubuilder is wine specific and so doing the scaling there would not have to be windows compliant. A quick google search seems to indicate that CLSID_WICIcnsEncoder is not a windows feature either. Although it might be better to synthesize a 32x32 rather than a 48x48 from a 64x64. *shrug* Just because 32 is half of 64? I will admit my understanding of image scaling is poor enough that i just assumed the closer the size the better the scale would turn out. -aric
Tr : d3dx9_36 [patch 1/3]: Fix the case out = in for D3DXSHRotateZ
Hi Both your patch and mine fail to pass the attached tests. More thoughts are needed. Nozomi Hi Nozomi, the huge arrays, the loop, it looks a bit ugly. Your implementation makes the D3DXSHRotateZ function a bit more compatible. What comes into my mind is: D3DXSHRotateZ(out, y, 1,25f, in); D3DXSHRotateZ(out, y, 1,25f, out); D3DXSHRotateZ(out, y, 1,25f, out[x]); // x ... 1 - y * y D3DXSHRotateZ(out[x], y, 1,25f, out); // x ... 1 - y * y Do the last 2 also work and are they producing the same values as native? Attached is a simple hack to succeed your test, it has some major stuff which needs to be fixed first, but nevertheless, please have a look. I think the implementation could be a lot smaller and faster. What do you think? I'd like to hear your opinion, before you try to send a patch. +FLOAT * WINAPI D3DXSHRotateZ(FLOAT *out, UINT order, FLOAT angle, CONST FLOAT *in) There is a double space after order,. Cheers Rico 0001-Add-tests-for-D3DXSHRotateZ.patch Description: Binary data
Re: (resend) programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Icns format
On Tue, Oct 16, 2012 at 7:40 PM, Ken Thomases k...@codeweavers.com wrote: Beyond that, perhaps the scaling should be put into the ICNS encoder rather than convert_to_native_icon(). That is, if it's handed a size that doesn't fit properly into one of the predefined slots, it would scale down to the next lower size. It would be far more difficult to make that change in the ICNS encoder than it is here. I think we should avoid it just so we can keep the code simple. I agree that scaling to 32x32 would probably work out better. Personally, I probably would've chosen 128x128, since that would involve no loss of information or distortion (but maybe we don't like the increased file size?). I guess it also depends on what size the OS uses to display the icon. If it will usually be a particular size, we should probably take that into account, though I don't know how much we can really do about it.
