On Fri, Sep 13, 2013 at 02:14:24PM -0700, Scott Ritchie wrote:
> Over the past couple years I've been able to try out Wine games on many
> different environments -- laptops, desktops, even cloud servers.
>
> On many occasions, I've discovered that a game appears to run
> functionally but slowly, h
Am 10.09.2013 11:44, schrieb Ralf Habacker:
>
> - remove misleading comment
Just for the record:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365804%28v=vs.85%29.aspx
do not mention any error code, which could be tested
If the function succeeds, it returns ERROR_SUCCESS.
If the funct
On 09/14/2013 12:14 AM, Scott Ritchie wrote:
Over the past couple years I've been able to try out Wine games on many
different environments -- laptops, desktops, even cloud servers.
On many occasions, I've discovered that a game appears to run
functionally but slowly, however upon further invest
> Probably, but as the patch comment says the code is based on gdiplus
> implementation, and there is no such an option flag in the corresponding
> gdiplus API params. I'd suggest to accept the patch as as, and make further
> improvements based on it.
Fair enough, the patch looks good otherwise.
Vincent Povirk wrote:
> Maybe the format for 32-bit bitmaps should be determined by the alpha
> channel options?
Probably, but as the patch comment says the code is based on gdiplus
implementation, and there is no such an option flag in the corresponding
gdiplus API params. I'd suggest to accept
Hi Scott,
On Linux power management decisions are made by cpufreq governors. Most
distributions I have used recently use the 'ondemand' scheduler, which
makes decisions as you would guess based on cpu load. This scheduler has
various parameters you can tweak in
'/sys/devices/system/cpu/cpufreq/ond
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
https://newtestbot.winehq.org/JobDetails.pl?Key=2196
Your paranoid andr
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
https://newtestbot.winehq.org/JobDetails.pl?Key=2195
Your paranoid andr
Maybe the format for 32-bit bitmaps should be determined by the alpha
channel options?
On Monday, September 16, 2013, Dmitry Timoshkov wrote:
> Based on a gdiplus implementation.
> ---
> dlls/windowscodecs/imgfactory.c | 149
+-
> dlls/windowscodecs/tests/bi
Ken Thomases writes:
> ---
> dlls/user32/driver.c | 12
> dlls/user32/user_private.h |1 +
> dlls/user32/winpos.c |2 ++
> 3 files changed, 15 insertions(+), 0 deletions(-)
It's better to avoid adding entry points that don't correspond to
Windows APIs. Instead you
On Sep 16, 2013, at 12:55 PM, Alexandre Julliard wrote:
> Ken Thomases writes:
>
>> ---
>> dlls/user32/driver.c | 12
>> dlls/user32/user_private.h |1 +
>> dlls/user32/winpos.c |2 ++
>> 3 files changed, 15 insertions(+), 0 deletions(-)
>
> It's better to avoid
> Thanks for you comments. The answer is yes, as you guessed.
> Typically, native GetGlyphOutlineW(hdc, ' ', GGO_BITMAP, &gm, 0, NULL, ...)
> returns gm.gmBlackBoxX = 1 instead of 0. Unfortunately, Wine's didn't,
> and existing source codes (winex11, gdiplus, gdi32) expect 0 in this
> case.
I don'
André Hentschel writes:
> ---
> dlls/kernel32/tests/file.c | 84
> ++
> 1 file changed, 84 insertions(+)
It doesn't work here:
../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p
kernel32_test.exe.so file.c && touch file.ok
file.c:810:
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
https://newtestbot.winehq.org/JobDetails.pl?Key=2187
Your paranoid andr
14 matches
Mail list logo