wine-devel May 2008

wine-devel@winehq.org

131 participants
254 discussions

Lots of regressions in games in last few versions
by Vitaliy Margolen 13 May '08

13 May '08

Several latest releases introduced lots and lots of regressions to a point that no games run as-is. Considering that we are at the code freeze, I'd like to see all patches that cause regressions, and all patches that depend on them starting from wine-0.9.58 be reverted. Also each patch to have a conformance test and statement which games where tested and what problems were fixed with each patch. Bugs: 13120, 13110, 13101, 13086 and on and on and on. Can some one explain what's the deal with games not working full screen? Why are there are of the sudden problems with pixel formats? Why lots of games crashing ActivatingContext? Why most games don't work anymore on ATI? If the whole point of wine-1.0 is to have photoshop working - then we might as well call it 'wine-photoshop' get it into a separate tree and don't let any changes not related to photoshop there. Vitaliy.

9 18

Re: [PATCH] Cache localised number chars
by Robert Shearman 13 May '08

13 May '08

Michael Karcher wrote: > UDATE *lpUdate) > static void VARIANT_GetLocalisedNumberChars(VARIANT_NUMBER_CHARS *lpChars, LCID lcid, DWORD dwFlags) > { > static const VARIANT_NUMBER_CHARS defaultChars = { '-','+','.',',','$',0,'.',',' }; > + static VARIANT_NUMBER_CHARS lastChars; > + static LCID lastLcid = -1; > + static DWORD lastFlags = 0; > LCTYPE lctype = dwFlags & LOCALE_NOUSEROVERRIDE; > WCHAR buff[4]; > > + /* Asking for default locale entries is very expensive: It is a registry > + server call. So cache one localy, as Microsoft does it too */ > + if(lcid == lastLcid && dwFlags == lastFlags) > + { > + memcpy(lpChars, &lastChars, sizeof(defaultChars)); > + return; > + } > + > This introduces a race condition. -- Rob Shearman

2 1

Re: includes: Add vmr9 header
by Robert Shearman 13 May '08

13 May '08

Maarten Lankhorst wrote: > @@ -0,0 +1,525 @@ > +/* > + * Copyright 2008 Maarten Lankhorst > + * > + * This library is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * This library is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with this library; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA > + */ > + > +#include "unknwn.idl" You should use import here, not #include. -- Rob Shearman

2 1

re: Lots of regressions in games in last few versions
by Dan Kegel 13 May '08

13 May '08

Vitaliy wrote: >> To get lots more people to try it and report bugs, so it can improve faster. >This is questionable. I can point to several bug reports that have several >dozen people reporting problems and that are still open for years. So just >saying more bug reports results into better Wine is not true. Sure, there are going to be hard bugs. Doesn't matter; on the whole, if we don't know about a bug, we can't fix it. And we need users to find the bugs for us, since only they really know how to use the apps. > Even targeted apps don't work perfectly - have some problems here and there. > People won't stand that. They already feed up with windows... When you get the bugs down below a certain point for a particular app, something funny happens: people start believing. And at that point they are willing to forgive a few issues. > The only loyal public Wine can have is gamers. And we still ignoring this fact. Because it's not a fact. It's a subjective conclusion you reached, but I do not share that opinion. Gamers are just as finicky as anyone else. > Oh and the whole point of wine-1.0 - and the way it's being > presented seems like a joke to me. Give me a break 4 apps?! > 3 of which being direct competitors to native Linux applications! > And such an old versions [97] that no one even uses them anymore. The release criteria are more about managing people's expectations. Underpromising and overdelivering. They're *supposed* to seem modest. Doesn't mean we don't care about other apps. > If anything we should be emphasizing that the code freeze is > to stabilize Wine and fix bugs. ALL bugs regardless of the app. I rather thought we were. That's the whole point of http://wiki.winehq.org/PlatinumRegressionHunt I'm not sure what you're angry about. None of us have that much control over exactly which way wine develops. We all scratch our own itches, and it improves at its own pace. What more do you want? - Dan

7 7

Re: [d3d9] shademode_test: increase slop in color comparison
by Stefan Dösinger 13 May '08

13 May '08

Am Montag, 12. Mai 2008 22:54:18 schrieb Dan Kegel: > The test allowed for a slop of (-1,0) in the colors, > but on my machine, > nVidia Corporation NV17 [GeForce4 440 Go 64M] > the colors were off by +1. So change the code > to allow for a slop of +-1, and switch to a more readable > way of comparing colors. Henri once said he had a universal patch for color slop he was going to send, I'm not sure what happened to it

1 0

Re: winex11: Create a dummy parent window for composite child windows to avoid using the root.
by Chris Robinson 13 May '08

13 May '08

Alexandre Julliard wrote: > - attrib.override_redirect = True; > attrib.colormap = data->colormap; > XInstallColormap(gdi_display, attrib.colormap); > > if(data->gl_drawable) XDestroyWindow(gdi_display, data->gl_drawable); > - data->gl_drawable = XCreateWindow(gdi_display, parent, -w, 0, w, h, 0, > + data->gl_drawable = XCreateWindow(gdi_display, dummy_parent, -w, 0, w, h, 0, > vis->depth, InputOutput, vis->visual, > CWColormap | CWOverrideRedirect, > &attrib); Did you mean to remove setting the override_redirect attribute? I remember having some alignment issues without it (the GL rendering was offset on the unseen window by the size of the decorations). But even if so, you'd need to remove the CWOverrideRedirect flag, because it's now taking the setting from the uninitialized override_redirect field.

2 1

Deprecated sound functions
by TheBlunderbuss 12 May '08

12 May '08

During the day's compile, I noticed some functions were declared deprecated, mainly in sound components. I logged more context, if anyone needs it. alsa.c:738: warning: ‘snd_pcm_hw_params_get_tick_time’ is deprecated (declared at /usr/include/alsa/pcm.h:1108) alsa.c:738: warning: ‘snd_pcm_hw_params_get_tick_time_min’ is deprecated (declared at /usr/include/alsa/pcm.h:1109) alsa.c:738: warning: ‘snd_pcm_hw_params_get_tick_time_max’ is deprecated (declared at /usr/include/alsa/pcm.h:1110) dscapture.c:451: warning: ‘snd_pcm_sw_params_set_xrun_mode’ is deprecated (declared at /usr/include/alsa/pcm.h:1101) dsoutput.c:213: warning: ‘snd_pcm_sw_params_set_xrun_mode’ is deprecated (declared at /usr/include/alsa/pcm.h:1101) wavein.c:486: warning: ‘snd_pcm_sw_params_set_xfer_align’ is deprecated (declared at /usr/include/alsa/pcm.h:1104) waveout.c:762: warning: ‘snd_pcm_sw_params_set_xfer_align’ is deprecated (declared at /usr/include/alsa/pcm.h:1104) waveout.c:764: warning: ‘snd_pcm_sw_params_set_xrun_mode’ is deprecated (declared at /usr/include/alsa/pcm.h:1101)

2 2

Where does richedit20.dll fit in the to-do list?
by Syam Babu.S 12 May '08

12 May '08

Dear Sir, While installing an application the installation stops for a long while copying ,Richedit20.dll, and finally I get the message cannot copy file may be disk full. I have more than 10 GB free. Can you enlighten me please ? Regards, Syam Babu

2 1

Re: Partial revert of c8bdebd... to fix bug #13093.
by Maarten Lankhorst 12 May '08

12 May '08

Hello Reece, 2008/5/12 Reece Dunn <msclrhd(a)googlemail.com>: > The patch "winealsa: Remove calls to deprecated functions." broke > audio playback on Cepstral SwiftTalker [bug #13093] (may also affect > other text-to-speech software like Dragon Naturally Speaking) when > running on Ubuntu 8.04 with pulseaudio+alsa (but may break on other > platforms). > > This patch reverts two of those lines that are needed to fix this > issue and generate clean WINEDEBUG=+wave,+dsalsa output. It seems the winealsa patch had too much ill side effects I didn't intend to happen, can you rather do a full revert? Cheers, Maarten.

1 0

Re: Lots of regressions in games in last few versions
by Vitaliy Margolen 12 May '08

12 May '08

James McKenzie wrote: > Vitaliy Margolen wrote: >> James McKenzie wrote: >>> Vitaliy Margolen wrote: >>>> Several latest releases introduced lots and lots of regressions to a >>>> point that no games run as-is. Considering that we are at the code >>>> freeze, I'd like to see all patches that cause regressions, and all >>>> patches that depend on them starting from wine-0.9.58 be reverted. >>>> >>>> Also each patch to have a conformance test and statement which games >>>> where tested and what problems were fixed with each patch. >>>> >>>> Bugs: 13120, 13110, 13101, 13086 and on and on and on. >>>> >>>> Can some one explain what's the deal with games not working full >>>> screen? Why are there are of the sudden problems with pixel formats? >>>> Why lots of games crashing ActivatingContext? Why most games don't >>>> work anymore on ATI? >>>> >>>> >>> Ya know there is a way to handle this. Bashing developers is not one >>> of them. Regression testing is. Some of our 'users' are not savvy >>> enough >> Oh really? So how many regression testing do you need to fix say... >> bug 11584 Multiple games crash with stack overflow error? 10? 20? 100 >> (look all the bugs marked as dups of it)? Unless some one actually >> starts fixing the bug, doing regression testing is pointless. Besides >> lots of new regressions have regression testing done on them. >> > There were several 'fixes' to this problem in the issue. And Stephan > continues to troubleshoot the problem. However, this is a VOLUNTEER > effort and most of us have 'real lives' to live. I would gladly work on > rich edit problems as they directly affect a program that I use. > However, I don't have enough hours in the day to attempt to work on > them. I picked up issue 6254, the lockup problem, and a patch proposed There are no patches that fix this problem (however hackish they might be). And it looks like a design problem. That's why someone with knowledge of the d3d needs to look at it. >> I'd like to trust all developers to make right decisions about what >> patches are low risk and which have to be tested with loads of apps. >> But it seems I can't. And no one saying what might break if some patch >> gets committed. And of course I understand that most things can't be >> tested with conformance tests there. But at least a minimum of several >> major titles have to be tested for regressions. >> >> > We need to do serious testing before any release. I lived in the QA Yes everything have to be tested. The business of sending patches that do "the right thing" have to stop. We all know that m$ always does things backwards. And most apps relay on that. > 'arena' for many years. However, we do have limited time and we don't > have all of the resources we'd like to have. Thus, some problems appear > in release code and we have to clean up the mess afterwards. In the No one should be cleaning up mess. There shouldn't be one in the first place. Or if some one got it in, it should be his responsibility to fix it, or get the whole damn thing out. > case of the issue you pointed out, the simple, but incorrect fix, was to > back out the change and then re-introduce it after some major work. > This would have delayed the improvement in framerates for many games and > productivity programs. And I tend to disagree with you there. I can point to number of things that weren't right to begin with. And it was clear right from the start. Yet they still not fixed, because now it's not trivial to fix the introduced problems. Or the whole idea was flowed and have to be redone. And I don't see what's so wrong with having 'git revert' as valid option for any problem patch? If problem is identified and it's not getting fixed before the next release - pull it out. This is the only option with our linear development where we don't have stable and development branches. Vitaliy

4 3

← Newer
1
...
14
15
16
17
18
19
20
...
26
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2008