http://bugs.winehq.org/show_bug.cgi?id=27320
Summary: sims3 crashes after a while in wined3d
Product: Wine
Version: 1.3.19
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: directx-d3d
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
sims3 is unstable on my son's computer under ubuntu 10.10 and 11.04,
and crashes after a few minutes of use.
wine --version says wine-1.3.19-248-g6a3255b
glxinfo says
OpenGL renderer string: GeForce GT 220/PCI/SSE2
OpenGL version string: 3.3.0 NVIDIA 270.41.06
c:/users/dank/My Documents/Electronic Arts/The Sims 3/xcpt pantry 11-05-28
07.00.36.txt
says
type: ACCESS_VIOLATION reading address 0xfeeeff06
address: 0x68211d3f "C:\windows\system32\wined3d.dll":0x0001:0x00040d3f
--
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.
http://bugs.winehq.org/show_bug.cgi?id=28723
Bug #: 28723
Summary: Sound stutter in Rage when emulated windows version is
set to "Windows 7" (XAudio2 -> mmdevapi sound out
path)
Product: Wine
Version: unspecified
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: winealsa.drv
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: mooroon2(a)mail.ru
CC: aeikum(a)codeweavers.com
Classification: Unclassified
Regression SHA1: b0652dd8bdb144645be4a6bf77cbb68a8ade49d9
This bug is twin-brother of fixed bug #28679. That one was when the app were
using dsound API, this one seems to be when app uses mmdevapi directly.
Same "first bad commit", reverting it fixes sound stutter in RAGE.
I don't know any other Windows app I've got installed on my workstation which
uses mmdevapi either directly or through XAudio2 (except for Starcraft II which
seems to be unaffected by either this bug and bug #28679).
Andrew, do you need usual sound-related debug logs for tracking this down? I
can capture them from RAGE but I'm afraid they would be a bit polluted by
unrelated messages from Steam client.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=27855
Summary: entry field in Quicken98-2002 follows keys rather than
filling out field
Product: Wine
Version: 1.3.24
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: jamesl(a)bestweb.net
Created an attachment (id=35625)
--> (http://bugs.winehq.org/attachment.cgi?id=35625)
Quicken98 sample data
(applies to Quicken98, Quicken 2000 and Quicken 2002. Have not tested against
Quicken99 or 2001)
In the window for writing checks, at the "payee" field, the normal behavior
under Windows is that the field will try to find a match according to what you
are typing. For example, if you were entering a check for "Sears Home Stuff",
you would type the letters s, e, a, r, s, and the field would fill out the
entry until it found the matching memorized transaction, which you could then
select and continue on filling out the rest of the fields.
Under Wine, in the same field if you type those letters, instead of filling out
the field, it will show the first memorized transaction that matches that
letter. Thus "S" would show "Saa...", "E" would show "Esso...", "A" would show
"Amiga...", and so forth. Entering new data (any payee not memorized) can be
difficult as well.
It is possible to enter text by forcing the field to show it's dropdown list,
but it's not what the user expects (in particular my older brother who
discovered this bug <g>).
Sample data files for the versions tested are attached. This bug occurs as
late as Wine 1.3.24, and at least as far back as CrossoverOffice 9.1 (and
whatever version of Wine that was based on).
--
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.
http://bugs.winehq.org/show_bug.cgi?id=28039
Summary: IAudioClock_GetPosition must ignore underruns (MacOS)
Product: Wine
Version: 1.3.25
Platform: x86
OS/Version: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: mmdevapi
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
GetPosition is critical because the new "winmm on mmdevapi" layer relies on it
for its buffer management. Currently, neither winealsa nor winecoreaudio
entirely fulfill GetPosition's contract.
GetPosition yields "the stream position of the sample that is currently playing
through the speakers". My tests show that it ignores underruns and is therefore
not identical to a clock. One can derive at least 2 tests from that:
1. GetPosition <= elapsed time * samples/sec (cannot hear the future).
2. GetPosition <= sum of samples fed to the device.
3. GetPosition == sum of samples once all have been played.
4. Getposition is monotically increasing (except when Reset).
Actually GetPosition does not yield samples, replace the above with GetPosition
/ GetFrequency * samples per sec to be correct.
My tests attached to bug #27937 show that:
- winecoreaudio fails test 3 (then 2).
- winealsa with dmix fails test 1 during the first seconds of play.
- winealsa with pulse fails test 1 much worse.
See bug #27937 comment #1 and 2 for log snippets.
On MacOS, GetPosition appears to continue to grow in the presence of underruns,
violating 2 and 3. Hence the name of the present issue.
Note that underruns are unknown to WINMM. A perfectly legal use is:
waveOutOpen()
waveOutPrepare(hugeboomheader)
waveoutPrepare(clickheader)
waveoutPrepare(ouchheader)
waveoutPrepare(beepheader)
then write the headers as the conditions arise (arguably dsound's mixing would
be more adequate). Guess what happens when GetPosition grows playing nothing
between 2 beeps?
--
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.
http://bugs.winehq.org/show_bug.cgi?id=13194
Summary: Gordian Knot unable to open codec settings dialog
Product: Wine
Version: 1.0-rc1
Platform: PC-x86-64
URL: http://sourceforge.net/projects/gordianknot
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: msvfw32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: emwine(a)earthlink.net
Created an attachment (id=13019)
--> (http://bugs.winehq.org/attachment.cgi?id=13019)
testcase source and exe
Install Codec Pack (for XviD), and rippack for GK. Run, go to options tab,
click "First Pass" under XviD default codec settings. Nothing. Same with
other codecs and "Codec settings" when trying a compressibility test.
GK is open source, but in pascal. So I created a small testcase in VC++ 6.0
using the same technique. Testcase relies on XviD as opposed to other codecs.
I'm not 100% sure that XviD (and other codecs) are properly registered so that
the technique ought to work. But I think the problem is not codec
registration. Also, I guessed at the component.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=16975
Summary: [StrongDC++] switching between tabs show background
windows
Product: Wine
Version: 1.1.12
Platform: PC
URL: http://strongdc.sourceforge.net/download.php?lang=eng
OS/Version: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: bazara.net(a)inbox.ru
If you open several tabs (windows) inside strongdc like hubs and click on a tab
to switch to another hub you should see how all other opened background windows
redraws until it show the one you clicked. If you have many opened hubs like 30
it will take several seconds to do that.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=30071
Bug #: 30071
Summary: Need a CreateTimerQueueTimer that is stable over time
Product: Wine
Version: 1.3.25
Platform: x86
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: ntdll
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: hoehle(a)users.sourceforge.net
Classification: Unclassified
Andrew Eikum's quick test in
http://www.winehq.org/pipermail/wine-devel/2012-February/094457.html
suggests that CreateTimerQueueTimer stabilizes itself over time on *average*.
For instance, when asked for a 12ms period, it will trigger 5 times within 60ms
even though it is unable to trigger every 12ms. The deltas are:
20, 10, 10, 10, 10, 20, 10, 10, 10, 10, ...
This is an essential property that it would share with winmm timers.
Both winealsa and wineoss today crucially depend on this property. The XAudio2
algorithm described in bug #28723 either writes one or zero period worth of
data per callback. Hence it requires callbacks to agree with frame consumption
by the audio device. If too late, XAudio2 will not catch up by writing 2
periods.
What currently happens is irregular crackling due to occasional underruns
because callbacks are further and further delayed and the audio buffers slowly
empties. Compare timestamps from apps using winmm with mmdevapi:
winmm mmdevapi
x.304 x.304
x.315 x.315
x.324 x.326
x.334 x.336
x.346 x.348
x.354 x.359
winmm corrects itself and manages to trigger all 10ms events on the same
millisecond as the initial one: x.xx4.
CTQT accumulates delays because as its core, queue_timer_expire uses:
[t->expire =] queue_current_time() + t->period;
I've separated this issue from bug #28723 because the root cause is not an
audio component and because several other bugs mention CreateTimerQueue, e.g.
bug #29585.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=31920
Bug #: 31920
Summary: ComboBox in a program written with Delphi is shown
incorrectly
Product: Wine
Version: 1.5.14
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: user32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: olelukoie(a)mail.ru
Classification: Unclassified
We at the company I work for have a tool written with Delphi and since one of
the recent wine devel versions (1.5.x) it shows its single combobox incorrectly
(no button with down-arrow on the right of the control and a very large black
area instead of a drop-down list).
git bisect gave me the following:
cbf9589ba397ed98d2aa2270a332171019024b3b is the first bad commit
commit cbf9589ba397ed98d2aa2270a332171019024b3b
Author: Sergey Guralnik <serhio(a)etersoft.ru>
Date: Wed Jul 4 23:34:57 2012 +0400
user32: Rearrange ComboBox repositioning code.
:040000 040000 2977ac3d4648b010663c10785732cc8e52b05a68
a6107e62617e0ec238f7c7a40c975c175b1c62f6 M dlls
I've tried to revert this commit in wine 1.5.14 and the problem disappeared
(combobox became normal and usable).
--
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.
http://bugs.winehq.org/show_bug.cgi?id=16263
Summary: Priority: Survive game window flickers
Product: Wine
Version: 1.1.9
Platform: PC
URL: http://solarimpact.servegame.com/files/ps-1.0.3.zip
OS/Version: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: arethusa26(a)gmail.com
Created an attachment (id=17537)
--> (http://bugs.winehq.org/attachment.cgi?id=17537)
Priority: Survive traces
With today's Git (wine-1.1.9-183-gbbaa72d), when running the Priority: Survive,
flickering can be noted ingame. irrespective of whether the virtual desktop is
enabled. I was unable to test whether different display modes changed the
flicking behavior since the game does not offer such an option. Traces are
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.
http://bugs.winehq.org/show_bug.cgi?id=27854
Summary: ListView_SetTextBkColor doesn't work
Product: Wine
Version: 1.3.24
Platform: x86
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: comctl32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ocean04(a)suomi24.fi
Source: http://www.delphidabbler.com/download?id=art-16
Download: http://netikka.net/dev/CustomLVDemo.exe
Text should be transparent, when checkbox is checked.
Not related to transparency. Even clRed instead of CLR_NONE doesn't set
background to red. Works with native comctl32
See also bug 27711
--
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.