December 2011 - Wine-Bugs - list.winehq.org

[Bug 29204] the dib text rendering breaks text in d3d

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=29204 Vitaliy Margolen <vitaliy-bugzilla(a)kievinfo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.voobly.com/updat | |es/voobly-v2.1.50.1.exe -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Dec. 1, 2011

[Bug 29155] Builtin IE with ICBC bank input control crash while closing

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=29155 --- Comment #7 from fracting <fracting(a)gmail.com> 2011-12-01 08:22:21 CST --- Hello, the simple html files below is useful for reproduce the bug: index.html: <html> <frameset > <frame name="indexFrame" src="index_1.html" /> </frameset> </html> index_1.html: <object id="safeEdit1" classid= "CLSID:73E4740C-08EB-4133-896B-8D0A7C9EE3CD" height="21" width="145"> </object> steps to reproduce: 1. setup a localhost server 2. open http://127.0.0.1:8000/index.html with wine iexplore 3. *double click* on the input control, then the control will be on focus, and wrapped by dotted lines 4. close iexplore Actual result: crash How reproducible: 100% here. new +mshtml trace will be attached -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Dec. 1, 2011

[Bug 29163] unable to trap mouse cursor under Mac OS X Lion 10.7.2

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=29163 kensenjiha(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WORKSFORME --- Comment #4 from kensenjiha(a)gmail.com 2011-12-01 06:05:09 CST --- disable dinput and dinput8 helps. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Dec. 1, 2011

[Bug 28723] Sound stutter in Rage when emulated windows version is set to "Windows 7" (XAudio2 -> mmdevapi sound output path)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=28723 --- Comment #64 from Alexey Loukianov <mooroon2(a)mail.ru> 2011-12-01 05:58:30 CST --- (In reply to comment #63) > What you describe is very interesting. I've rarely used hw:0 myself as I > typically use a converter plugin to allow 8000x8x1. emu10k1 allows to use "almost arbitrary" rate/bps/chan combos doing required conversions in hw (or in kernel space - hadn't had a chance to look at emu10k1 sources) so all the test's I've been ever doing had been done like hw vs. dmix plug only vs. rate plug only vs plug+dmix combo. You'd be surprised how many gotchas and black areas are there when some perfectly correct access schemes work as expected with direct hw access and fails silently when using some alsa-lib plugins. > I've hit a new variant yesterday with dmix: Given a period of 170 frames, play > Nx170 silence (N>=1), then 169 noise and wait. Underrun is entered but the > noise is never heard. Dmix (or the rate converter you described) is again > waiting for a full period. I had spent some time yesterday looking at alsa-lib sources. I think that it's not dmix who causes the behavior you describe, most likely it is rate plugin again. Take a look at it's sources (http://git.alsa-project.org/?p=alsa-lib.git;a=blob_plain;f=src/pcm/pcm_rate…) grep for "start_pending" and the root cause of the problem would become obvious for you. > This reminds me of test results on vista, where padding frames are left > unconsumed after underrun. Not so with w7. Oh, thanks for reminding about this. I would try to repeat the same tests I've done for alsa-lib rate/dmix on laptop with Vista installed - today it had finally arrived at my disposition and going stay here for a next few days. > It means that the last milliseconds of any sound are not played in Wine using > dmix unless the app adds silence -- which is what MSDN > recommends for mmdevapi. Well, they don't actually recommend it - they just describe a way that the provided example code is expected to work. What they actually do is append about half a buffer of silence to the end of real audio samples just to make sure that the audio engine wouldn't use stale data residing in a ring buffer and thus it "prevents unwanted sounds before the call to the IAudioClient::Stop method stops the audio stream." Actual tests using your N*period silent frames + (period-1) of noise (sine wave in my case) produce a beep on win7. Would try to test with Vista today and report back. > I'm sorry GetPosition is not ready. Yesterday I had a case with PulseAudio > where the first call to snd_pcm_delay after starting to play returned -5. Smells like -EIO. Was the call successful or it was just the delay_frames that been set to a negative value? Is it a repeatable result or not? > Second, I've had cases where PulseAudio avail_update > returned ~1.8s worth of frames, much more than the 50ms buffer_size I set. So > computing alsa_padding as buffer_size-avail_update does not work. I'm not > amused. Certainly it is a bug in pulse alsa-plugin. Yeah, ALSA codebase is not the finest thing ever by itself, but bugs in PA-related stuff sometimes make me rage (you know, spending several days debugging just to find out that it's yet another PA-related bug I have to invent a workaround for). Back on topic, in any case we need some data source from the ALSA part of a world to get an idea about current padding and/or delay. The fact that reported avail_update and delay values can't be always trusted gives us a misery but there's not too much at all we can do about it except for filing-out bug reports to alsa and/or PA bug trackers. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Dec. 1, 2011

[Bug 29039] League Of Legends game client crashes after champion selection

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=29039 --- Comment #13 from Bruno Jesus <00cpxxx(a)gmail.com> 2011-12-01 05:34:16 CST --- (In reply to comment #10) > I actually got the standard LoL client to work just fine using wine-1.3.32 > WITHOUT the "ws2_32: Handle NULL and empty hostname correctly in getaddrinfo" > patch attached in this bug (the patch that has now been comitted to > wine-1.3.33). There was already a new bug and already a fix in git. http://bugs.winehq.org/show_bug.cgi?id=29145 Fix: http://source.winehq.org/git/wine.git/commit/8e5d5bf58aa4ad9ac638f0b6e6473b… If after testing in git you still have a problem you can open a new bug as the previous comment suggests. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Dec. 1, 2011

[Bug 29208] Extreme high CPU usage from unknown hang

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=29208 --- Comment #3 from me(a)haravikk.com <me(a)haravikk.com> 2011-12-01 04:58:59 CST --- It hangs completely; whatever WINE is doing it's utterly locked up, I have to force the program closed to regain use of my machine. I can run the game normally under emulation or by booting to Windows, but under WINE it won't work at all, yet all I can think it should be doing is enabling the "Play" button, as it gets passed the file-verification/download steps just fine. I mean, it's entirely possible it is partly the fault of the game as well, but I don't see why WINE's load should increase so dramatically, and can't figure out what it's doing. Does the stack trace hold any clues? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Dec. 1, 2011

[Bug 28723] Sound stutter in Rage when emulated windows version is set to "Windows 7" (XAudio2 -> mmdevapi sound output path)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=28723 --- Comment #63 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2011-12-01 04:52:30 CST --- What you describe is very interesting. I've rarely used hw:0 myself as I typically use a converter plugin to allow 8000x8x1. I've hit a new variant yesterday with dmix: Given a period of 170 frames, play Nx170 silence (N>=1), then 169 noise and wait. Underrun is entered but the noise is never heard. Dmix (or the rate converter you described) is again waiting for a full period. This reminds me of test results on vista, where padding frames are left unconsumed after underrun. Not so with w7. It means that the last milliseconds of any sound are not played in Wine using dmix unless the app adds silence -- which is what MSDN recommends for mmdevapi. http://msdn.microsoft.com/en-us/library/windows/desktop/dd316756%28v=VS.85%… I'm sorry GetPosition is not ready. Yesterday I had a case with PulseAudio where the first call to snd_pcm_delay after starting to play returned -5. GetPosition should return 0+old_samples in that case, which would need a new variable old_samples to cumulate samples played until the last underrun (may be valuable for MacOS too). Second, I've had cases where PulseAudio avail_update returned ~1.8s worth of frames, much more than the 50ms buffer_size I set. So computing alsa_padding as buffer_size-avail_update does not work. I'm not amused. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Dec. 1, 2011

[Bug 29204] the dib text rendering breaks text in d3d

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=29204 PommeGolden <lapommegolden(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lapommegolden(a)gmail.com --- Comment #5 from PommeGolden <lapommegolden(a)gmail.com> 2011-12-01 04:45:03 CST --- Programs written in QT4 (especially the UI) also have similar problem, e.g. Voobly, tsMuxer GUI UI texts appear lighter / thiner / brighter / less solid than expected. Looks like something is wrong with with the text gamma or antialising. Adjusting FontSmoothingGamma value in registry can temporarily make the texts more solid for now. Voobly can be downloaed here: http://www.voobly.com/updates/voobly-v2.1.50.1.exe -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Dec. 1, 2011

[Bug 29144] skyrim freeze starting new game with ati/catalyst

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=29144 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan(a)codeweavers.com --- Comment #16 from Stefan Dösinger <stefan(a)codeweavers.com> 2011-12-01 04:26:19 CST --- I have occasional contact with AMD and was about to file a bug in their official Bugzilla. I didn't hit the submit button when I realized that their only options are violating the GL_NV_half_float spec(which would be hacky) or writing a new extension(which I consider an overkill for the legacy immediate mode functions). I'd say GL_ARB_instanced_arrays is the best way to go if we want to avoid the extra type conversion. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Dec. 1, 2011

[Bug 25965] Bioshock: Big daddies are surrounded by red fog

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=25965 Loris Zinsou <the-lz-himself(a)orange.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |the-lz-himself(a)orange.fr --- Comment #5 from Loris Zinsou <the-lz-himself(a)orange.fr> 2011-12-01 03:42:32 CST --- Still happens in wine 1.3.33 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

Dec. 1, 2011