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

newtestbot timings

by Joerg-Cyril.Hoehle＠t-systems.com

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

Feb. 22, 2013

Re: [0/13] Patch series description

by Saulius Krasuckas

* On Thu, 21 Feb 2013, André Hentschel wrote: > Am 21.02.2013 21:31, schrieb Saulius Krasuckas: > > > > because I've got new(er) Sparc machine. > > You know that you most likely won't ever be able to run x86 apps on that > machine, only winelib. Do you need that for something? Yes, I am aware of endianess issue found by Darwine people when integrating it with Qemu to run x86/PE binaries on PowerPC: http://wiki.winehq.org/MacOSX It is said byteswapping isn't worth trouble but if Rosetta did it (only in reverse direction) isn't this issue only about developers work time and not about performance? Then it seems Sparc V9 can switch to little endian to access data. > So where do we go from here? Right to the binary translation (or even dynamic recompilation), I guess. S.

Feb. 22, 2013

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Johannes Kroll wrote: >I don't understand what you mean by "decompose LongMsg into snippets". >Is it possible that either >A) the app expects the API code to scan the buffer for a trailing 0xf7 >end marker and send only the bytes up to that marker; or >B) that the mysterious "dwBytesRecorded" should really contain the >bytes to be sent, and that it should be set by a function calling >LongMsg (i. e. somewhere else in Wine)? We have no evidence that dwBytesRecorded shall be used. Neither A nor B. I'll explain. Net.wisdom has it that midiOutLongMsg can be used to play chords, e.g. send 2 note-on events: 91 K1 V1 92 K2 V2 If MIDI worked only over the serial port, there would be no complication: Simply send all those bytes over the serial port. Let the receiver handle them. The OSS interface works like this: just dump bytes one by one. http://source.winehq.org/source/dlls/wineoss.drv/midi.c?v=wine-1.5.23#L1559 That's why I believe OSS would work fine as is with your app. The ALSA interface is much more complex. It expects markup - use snd_seq_ev_set_sysex() for a SysEx, - use snd_seq_ev_set_noteoff() for NOTE_OFF, - snd_seq_ev_set_noteon|keypress|controller|... http://source.winehq.org/source/dlls/winealsa.drv/midi.c?v=wine-1.5.23#L844 Therefore, winealsa needs to scan the buffer and decompose it into snippets, then call the matching snd_seq_ev_set_* function. So winealsa must call snd_seq_ev_set_noteon on each 91 K1 V1 snippet. In the case of your app it would call snd_seq_ev_set_sysex on the F0...F7 snippet, then ... well I don't know what to call on the remaining three 00 00 00 bytes. The "simply send bytes over the serial port" analogy would mean to not skip those bytes rather than find some means to send them via ALSA. Regards, Jörg Höhle

Feb. 22, 2013

Re: vbscript: Added support for a few more constants.

by Marvin

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

Feb. 22, 2013

Re: comctl32/treeview: Protect TVM_GETITEM from invalid item pointers

by Nikolay Sivov

On 2/22/2013 14:09, Alexandre Julliard wrote: > Nikolay Sivov <nsivov(a)codeweavers.com> writes: > >> @@ -2101,9 +2102,17 @@ TREEVIEW_GetItemT(const TREEVIEW_INFO *infoPtr, LPTVITEMEXW tvItem, BOOL isW) >> { >> if (!item) return FALSE; >> >> - TRACE("got item from different tree %p, called from %p\n", item->infoPtr, infoPtr); >> - infoPtr = item->infoPtr; >> - if (!TREEVIEW_ValidItem(infoPtr, item)) return FALSE; >> + __TRY >> + { >> + infoPtr = item->infoPtr; >> + TRACE("got item from different tree %p, called from %p\n", item->infoPtr, infoPtr); >> + if (!TREEVIEW_ValidItem(infoPtr, item)) return FALSE; > You can't return from a try block. Ah, thanks. > > Also have you verified that this is not just masking some other Wine > bug? Honestly, I have not. I only looked at +treeview log attached to bug. Will try to figure out what's going on exactly.

Feb. 22, 2013

Re: server/advapi32: Report administrator ownership by default for registry objects (try 4).

by Alexandre Julliard

"Erich E. Hoover" <ehoover(a)mymail.mines.edu> writes: > + else > + { > + struct object_type *type = obj->ops->get_type( obj ); > + static const WCHAR key_type[] = {'K','e','y'}; > + const WCHAR *type_name = NULL; > + data_size_t type_len = 0; > + > + if (!type) goto done; > + type_name = get_object_name( &type->obj, &type_len ); > + release_object( type ); > + if (memcmp(type_name, key_type, type_len) != 0) goto done; > + } You clearly need to spend more time studying how the server works. -- Alexandre Julliard julliard(a)winehq.org

Feb. 22, 2013

Re: comctl32/treeview: Protect TVM_GETITEM from invalid item pointers

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > @@ -2101,9 +2102,17 @@ TREEVIEW_GetItemT(const TREEVIEW_INFO *infoPtr, LPTVITEMEXW tvItem, BOOL isW) > { > if (!item) return FALSE; > > - TRACE("got item from different tree %p, called from %p\n", item->infoPtr, infoPtr); > - infoPtr = item->infoPtr; > - if (!TREEVIEW_ValidItem(infoPtr, item)) return FALSE; > + __TRY > + { > + infoPtr = item->infoPtr; > + TRACE("got item from different tree %p, called from %p\n", item->infoPtr, infoPtr); > + if (!TREEVIEW_ValidItem(infoPtr, item)) return FALSE; You can't return from a try block. Also have you verified that this is not just masking some other Wine bug? -- Alexandre Julliard julliard(a)winehq.org

Feb. 22, 2013

Re: gdi32: Fix the GdiGetCodePage() support ANSI_CHARSET font associated charset.

by Qian Hong

On Fri, Feb 22, 2013 at 10:21 AM, Byeongsik Jeon <bsjeon(a)hanmail.net> wrote: > This patch fix a original topic of the wine-bugs #16325. Thanks for the great work! I've been waiting for this fix for a really long time :) Out basic Wine test VM does not include Chinese/Japanese Windows, so I submit Byeongsik's patch to the testbot again with Chinese/Japanese Windows included: https://testbot.winehq.org/JobDetails.pl?Key=24496 All tests related to this patch passed (Those failed tests are not related to this patch) I also manually test the patch on Windows with Korean locale and the test case passed as well. Hopes that helps :) -- Regards, Qian Hong - http://www.winehq.org

Feb. 22, 2013

Re: [0/13] Patch series description

by André Hentschel

Am 21.02.2013 21:31, schrieb Saulius Krasuckas: > * On Thu, 21 Feb 2013, André Hentschel wrote: > >> Really? :) I mean this was 2004, and it doesn't look like you took >> action on this. Did you read e.g. http://wiki.winehq.org/SPARC or >> http://bugs.winehq.org/show_bug.cgi?id=24142 in the meantime? > > Well, I didn't took actions but such intention is still present. Just > because I've got new(er) Sparc machine. > You know that you most likely won't ever be able to run x86 apps on that machine, only winelib. Do you need that for something? So where do we go from here? -- Best Regards, André Hentschel

Feb. 21, 2013

Re: [0/13] Patch series description

by Saulius Krasuckas

* On Thu, 21 Feb 2013, André Hentschel wrote: > Really? :) I mean this was 2004, and it doesn't look like you took > action on this. Did you read e.g. http://wiki.winehq.org/SPARC or > http://bugs.winehq.org/show_bug.cgi?id=24142 in the meantime? Well, I didn't took actions but such intention is still present. Just because I've got new(er) Sparc machine. I've been reading this wiki page from time to time but haven't been into the bugreport. Thanks for it:) S.

Feb. 21, 2013