February 2013 - Wine-devel - list.winehq.org

Re: user32/tests: Test invalidating during SetWindowPos() (resend).
by Sergey Guralnik 25 Feb '13

25 Feb '13

On 2013-02-21 15:44, Sergey Guralnik wrote: > This patch marked as "Pending" without any comment at wine-devel. Is something wrong with it? (Maybe there should be more test cases?) -- Sergey

2 1

Re: [1/3] gdiplus: Add some tests for ARGB conversions.
by Nikolay Sivov 25 Feb '13

25 Feb '13

On 2/25/2013 09:29, Dmitry Timoshkov wrote: It seems your system time is an hour ahead. Probably old timezone info?

1 0

Why complain about X1R5G5B5?
by Francois Gouget 24 Feb '13

24 Feb '13

If I run Wine's conformance tests in a QEmu VM using Spice's QXL driver I get the following errors: d3d8:device device.c:1004: Test failed: Unexpected display mode returned for mode 0: 0x18 d3d9:device device.c:1366: Test failed: EnumAdapterModes(D3DFMT_X1R5G5B5) did not return D3DERR_INVALIDCALL (got 00000000)! In essence our tests say that the driver must not support X1R5G5B5. Why? Further notes: * If I then call Direct3D9::CheckDeviceType() for this format I get NOTAVAILABLE which is inconsistent. But then that's exactly what Microsoft's Standard VGA driver does for the R5G6B5 and X8R8G8B8 formats. http://www.winehq.org/pipermail/wine-patches/2013-February/122388.html * See the exact list of formats returned by IDirect3D8::EnumAdapterModes() http://newtestbot.winehq.org/JobDetails.pl?Key=243&log_103=1#k103 Test executable and source: https://bugs.freedesktop.org/attachment.cgi?id=75248 * See the list of formats that IDirect3D8::EnumAdapterModes() claims are supported, and how CheckDeviceType() refuses them. http://newtestbot.winehq.org/JobDetails.pl?Key=249&log_103=1#k103 Test executable and source: https://bugs.freedesktop.org/attachment.cgi?id=75260 * I think it's important to get Spice's QXL driver and Wine's conformance tests to play nice together. First they are both open-source so if one is wrong we should work to resolve that. But also the new WineTestBot is uses QEmu and the QXL driver looks like it will be _the_ paravirtualized(*) graphics driver there. (*) I.e. high performance and most used driver. * See also QXL bug 61227: https://bugs.freedesktop.org/show_bug.cgi?id=61227 -- Francois Gouget <fgouget(a)codeweavers.com>

3 4

Re: A new demangler test?
by Nikolay Sivov 24 Feb '13

24 Feb '13

On 2/24/2013 15:13, Eric Pouech wrote: > Le 24/02/2013 10:18, Nikolay Sivov a écrit : >> On 2/24/2013 10:07, Max TenEyck Woodbury wrote: >>> On 02/23/2013 02:54 AM, Eric Pouech wrote: >>>> Le 21/02/2013 14:33, Max TenEyck Woodbury a écrit : >>>>> Would it be appropriate to add a test to the name demangler that: >>>>> >>>>> 1) Scans all '.dll' and '.spec' files for mangled names, and >>>>> >>>>> 2) Tries to decode those names. >>>>> >>>>> 3) Prints the mangled and decoded names and where they occur. >>>>> >>>>> Success would be that all names decode without the decoder blowing up >>>>> or failing. >>>>> >>>>> >>>>> >>>> adding tests for demangler is good >>>> but you just need to have a set of mangled/unmangled strings for >>>> the test >>>> as core demangler in msvcrt, test should be added here... >>>> (but grabbing the mangled strings shall be left out of the test >>>> itself) >>>> A+ >>>> >>> One of the important aspects of name demangling is that it should work >>> on _all_ the names in the current system. The current test does >>> demangle a list of known strings, but that list was incomplete with >>> respect to all the features used in real names the last time I dug into >>> the details (which was none too recently). >>> >>> Scanning for all the real mangled names not only makes sure that the >>> demangler is working properly, it also assures that all the names used >>> are properly formed and decode to their intended values. >> I don't see a point to extend test data that much, it's enough to add >> some most common cases, >> and add more when something breaks because of it. Otherwise it >> doesn't deserve that much of attention imho. >> >> By the way, do you see something broken or it's just something you >> want to work on? >>> >>> > there are lots of broken stuff (in msvcrt), and demangler in winedump > is ante-deluvian (and doesn't share its code with msvcrt) > A+ Okay, don't know if winedump part is of any use, I mean it tries to provide a sane C name for decorated names, and usually such names are hand-crafted anyway later. Msvcrt being broken is important of course (at least for dbghelp).

1 0

Re: [0/13] Patch series description
by Saulius Krasuckas 23 Feb '13

23 Feb '13

* On Wed, 20 Feb 2013, André Hentschel wrote: > this patch series removes the broken SPARC support. > Reasons: > * It's broken, i wasted enough time already trying to fix that It's sad to hear. Can you be more verbose on brokenness, please? Eg. namely what Sparc platform were you using for development? > * Nobody cares - I sent an e-mail to everyone ever related to > Wine/SPARC based on addresses from our mailing lists - no answer in a > week (and cw also has no customers for it) You didn't catch this then: http://www.winehq.org/pipermail/wine-devel/2004-October/030355.html I care :) > * If someone _would_ care the right thing to do would be a clean SPARC > 64-bit port So, the old port was 32-bit or mixed or what? > * It really can confuse people (more than a ARM/ARM64 port xD) You mean random readers about host platforms Wine runs on;)? > * SPARC is dead on the Desktop :( > And last but not least: I had a bad experience with the Solaris > community regarding Wine/SPARC Oh. Is there any related public messages on the net? It would interesting to read and know those stories. S.

2 6

Re: gdiplus: Remove debug traces from GdipBitmapGetPixel and GdipBitmapSetPixel.
by Vincent Povirk 22 Feb '13

22 Feb '13

> alpha_blend_bmp_pixels() calls them while copying bitmap bits with an > alpha channel. This makes debug logs huge, hard to analyze, and completely > unmanagable in size. GDI+ should be fixed so it doesn't call these functions internally. It's just not an efficient way to render to bitmaps.

1 0

Re: gdi32: Fix the GdiGetCodePage() support ANSI_CHARSET font associated charset.
by Akihiro Sagawa 22 Feb '13

22 Feb '13

On Fri, 22 Feb 2013 11:21:20 +0900, Byeongsik Jeon wrote: > This patch fix a original topic of the wine-bugs #16325. Thanks for your work on this. > +static DWORD get_associated_charset_info(void) > +{ > + static DWORD associated_charset = -1; > + > + if (associated_charset == -1) > + { > + const char *assoc_charset_reg_key = > + "System\\CurrentControlSet\\Control\\FontAssoc\\Associated Charset"; Please use WCHARs and W version of APIs in gdi32/font.c, like: const WCHAR yesW[] = { 'Y', 'E', 'S', 0 }; and so on. > @@ -3615,6 +3615,33 @@ static void update_font_info(void) > } > if (!done) > FIXME("there is no font defaults for codepages %u,%u\n", ansi_cp, oem_cp); > + > + if (RegCreateKeyA( HKEY_LOCAL_MACHINE, > + "System\\CurrentControlSet\\Control\\FontAssoc\\Associated Charset", As far as I know, in SBCS locale, this key doesn't exist. Therefore it should delete in SBCS locale initialization and create the key in DBCS locale initialization. Regards, Akihiro Sagawa

1 0

newtestbot timings
by Joerg-Cyril.Hoehle＠t-systems.com 22 Feb '13

22 Feb '13

Hi, I've looked at some of newtestbot timing results. http://newtestbot.winehq.org/JobDetails.pl?Key=256 It's not too bad, but it's not superb either. >render.c:633: event after Stop.4 average 40.000ms deviation 0.06 from 100 samples That's exactly the expected 40ms, great! >render.c:618: Test failed: Wait iteration 40 gave 102 >render.c:633: event after Stop.1 average 10.925ms deviation 0.36 from 40 samples That's funny. I recently discovered that the Vista-w7 machines downgrade their event rate from 10 to 40.0ms exactly 2 seconds following IAC_Stop. Newtestbot's w8 results indicate that w8 continues sending 10ms events for 400ms after IAC_Stop, then ceases. Current wine*.drv immediately stop sending events after IAC_Stop, so Wine almost implemented w8 behaviour before it existed :-) >render.c:189: Returned periods: 10.1587 ms 3.0000 ms >render.c:633: event after Start.2 average 10.955ms deviation 0.16 from 100 samples >render.c:2200: Released 44800=100x448 -448 frames at 44100 worth 1006ms in 1087ms >render.c:2206: event average 10.878ms deviation 0.16 from 100 samples So the machines do not manage to deliver the expected 10.1587ms period. Well, 10.9 is not that far away. By comparison, a native box meets the average: < event after Start.4 average 10.159ms deviation 0.01 from 100 samples < Released 44800=100x448 -896 frames at 44100 worth 996ms in 1018ms < event average 10.161ms deviation 0.03 from 100 samples The exclusive mode test shows some degradation: >render.c:928: Testing exclusive mode at 44100 >render.c:948: Latency: 15.0113 ms >render.c:967: BufferSize 22528 estimated fragment 662 x 33 = 21846 >render.c:991: Clock Frequency 44100 >render.c:1060: Test failed: Position 5696 too far after stop 100ms -- 129ms 30% off, quite a lot. >render.c:1070: padding 0 past sleep #2 >render.c:1089: padding 0 position 22528 past stop #2 This is worrying. Padding 0 means that within 200ms, the driver emptied its whole half second buffer. That's not physical. Do you have PulseAudio running on the UNIX VM host? It's known from winealsa to eat lots of samples when starting up. By contrast, a native box yields: < padding 13308 past sleep #2 < padding 13251 position 9277 past stop #2 -- 210ms >render.c:1148: position 6208 past 100ms sleep #3 -- 141ms >render.c:1152: Test failed: Position 6208 too far after playing 100ms >render.c:1168: padding 16256 position 6272 past stop #3 -- 142ms >render.c:1173: Test failed: Position 6272 too far after stop 100ms Again, a native box yields values fully in range: < position 4757 past 100ms sleep #3 -- 108ms < padding 17706 position 4822 past stop #3 -- 109ms Interestingly, only exclusive mode is affected by huge deviations, upto 50%. Regarding shared mode, oddly w8 machines exhibit some failures. They are quite small (I think we should raise the margins to fit): render.c:1060: Test failed: Position 39424 too far after stop 100ms -- 111ms render.c:1060: Test failed: Position 43008 too far after stop 100ms -- 121ms render.c:1094: Test failed: Position 78848 too far after playing 200ms --223ms One machine stalled for 44 seconds: >render.c:633: event after Stop.2 average 444.809ms deviation 4294.73 from 100 samples That would have caused a test failure if it had happened at another location within the tests. Regards, Jörg Höhle

1 0

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().
by Joerg-Cyril.Hoehle＠t-systems.com 22 Feb '13

22 Feb '13

Hi, Johannes Krol wrote: >Joerg, if you want the complete log I can send it to you by PM, it's >about 1.7M. I don't need that for now. What I need are the 119 missing bytes between 17.015:003b:trace:midi:modLongData dwBufferLength=125 ! 17.015:003b:trace:midi:modLongData F0 42 40 ... 00 00 00 Please copy&paste & adapt this code to produce a full hex dump: http://source.winehq.org/source/dlls/winmm/winmm.c#L1066 In particular, I want to know if there's some F7 amid that data (remember that your original patch precisely stopped at a F7...) and what the bytes following that F7 look like. >This could be interpreted to mean that Windows will add the 0xF7 >marker, if it was missing, when any other MIDI message is sent. That's a possible interpretation, however your log snippet shows no sign of sending another message. Do you have MIDI/ALSA debugging tools that can show you whether ALSA truly sends out the 125 bytes? That too would help identify the problem. Thank you, Jörg Höhle

2 6

Re: vbscript: Added support for a few more constants.
by Marvin 22 Feb '13

22 Feb '13

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=24500 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

1 0