Alright, this is probably the last time I will bring it up before I realize that there is essentially no interest in fixing this, but this has been bothering me for quite some time now. A few others have brought it up over the past couple months as well.
http://www.winehq.org/hypermail/wine-cvs/2004/10/0395.html
As discussed (but nothing really done about it), this patch is directly known to break painting in at least the following applcations: DeusEx Trickstyle Foobar2000 Zoo Tycoon 1 demo
This is because, as far as I'm aware, these applications don't send BeginPaint/EndPaint as they technically should, but they all work fine on native Windows. Now, before, it has simply been a matter of reversing the patch, no big deal. However, since the region handling has been moved to the server, that is not possible without a lot of tinkering, something that I just don't have the mad skillz to do.
--Nick
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com
Nick Hornback vidar268@yahoo.com writes:
Alright, this is probably the last time I will bring it up before I realize that there is essentially no interest in fixing this, but this has been bothering me for quite some time now. A few others have brought it up over the past couple months as well.
There is a lot of interest in fixing it, but it's far from trivial especially for apps that I don't have. You can help by posting traces (+server,+win,+message is usually a good start) of the offending behavior.
On 12 Feb 2005 20:42:37 +0100, you wrote:
Nick Hornback vidar268@yahoo.com writes:
Alright, this is probably the last time I will bring it up before I realize that there is essentially no interest in fixing this, but this has been bothering me for quite some time now. A few others have brought it up over the past couple months as well.
There is a lot of interest in fixing it, but it's far from trivial especially for apps that I don't have. You can help by posting traces (+server,+win,+message is usually a good start) of the offending behavior.
ClipRgn.exe has the same or a similar problem. It uses GetDCEx instead of BeginPaint when it wants a different clip region then the default.
ClipRgn.exe can be downloaded from: http://www.codeproject.com/gdi/ClipRgnGuide/ClipRgn_demo.zip Sources are here: http://www.codeproject.com/gdi/ClipRgnGuide/ClipRgn_src.zip
(free registration for www.codeproject.com required)
Describing article is at http://www.codeproject.com/gdi/cliprgnguide.asp
To reproduce the bug: - start ClipRgn.exe - select from the View menu, "Manual System Region" - draw a clip region with the mouse and left button held down. - force a WM_PAINT event by obscuring and exposing its window. (screen flickers from an endless repainting)
You may want to apply the FrameRgn fix that I sent today first, so you can see the clip region.
Rein.
On Sun, 2005-02-13 at 13:52, Rein Klazes wrote:
On 12 Feb 2005 20:42:37 +0100, you wrote:
Nick Hornback vidar268@yahoo.com writes:
Alright, this is probably the last time I will bring it up before I realize that there is essentially no interest in fixing this, but this has been bothering me for quite some time now. A few others have brought it up over the past couple months as well.
There is a lot of interest in fixing it, but it's far from trivial especially for apps that I don't have. You can help by posting traces (+server,+win,+message is usually a good start) of the offending behavior.
ClipRgn.exe has the same or a similar problem. It uses GetDCEx instead of BeginPaint when it wants a different clip region then the default.
Hi,
I remembered am email on wine-devel a while ago:
http://www.winehq.org/hypermail/wine-patches/2004/10/0139.html
I hoped this was relevant and tested out his redraw.c tests. They all succeed on my win98/winnt/win2k and winxp machines and fail on Wine:
[paul@penguin tests]$ make redraw.ok ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so redraw.c && touch redraw.ok redraw.c:121: Test failed: LB_SETTOPINDEX: Listbox should redraw itself redraw.c:149: Test failed: EM_REPLACESEL: Single-line edit control should redraw itself redraw.c:155: Test failed: EM_SETSEL: Single-line edit control should redraw itself redraw.c:161: Test failed: WM_CUT: Single-line edit control should redraw itself redraw.c:167: Test failed: WM_PASTE: Single-line edit control should redraw itself
Although the mail talks about redrawing listboxes and edit-controls, could this also be true for windows/controls in general?
Cheers,
Paul.
P.S. Should I send the test to wine-patches?
Paul Vriens Paul.Vriens@xs4all.nl writes:
I remembered am email on wine-devel a while ago:
http://www.winehq.org/hypermail/wine-patches/2004/10/0139.html
I hoped this was relevant and tested out his redraw.c tests. They all succeed on my win98/winnt/win2k and winxp machines and fail on Wine:
[paul@penguin tests]$ make redraw.ok ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so redraw.c && touch redraw.ok redraw.c:121: Test failed: LB_SETTOPINDEX: Listbox should redraw itself redraw.c:149: Test failed: EM_REPLACESEL: Single-line edit control should redraw itself redraw.c:155: Test failed: EM_SETSEL: Single-line edit control should redraw itself redraw.c:161: Test failed: WM_CUT: Single-line edit control should redraw itself redraw.c:167: Test failed: WM_PASTE: Single-line edit control should redraw itself
Although the mail talks about redrawing listboxes and edit-controls, could this also be true for windows/controls in general?
Not in general, but yes there are a number of cases where redraws are synchronous on Windows and there are some apps that depend on that. It wasn't done that way in Wine mostly because it caused a lot of unnecessary refreshes, but now that we no longer get expose events on child windows we can move towards more synchronous behavior.
On Sat, 12 Feb 2005, Alexandre Julliard wrote:
Nick Hornback vidar268@yahoo.com writes:
Alright, this is probably the last time I will bring it up before I realize that there is essentially no interest in fixing this, but this has been bothering me for quite some time now. A few others have brought it up over the past couple months as well.
There is a lot of interest in fixing it, but it's far from trivial especially for apps that I don't have.
Zoo Tycoon 1 Demo can be downloaded from there:
http://www.microsoft.com/games/zootycoon/zoo1/downloads.asp
Unless this is something different.
--- Alexandre Julliard julliard@winehq.org wrote:
There is a lot of interest in fixing it, but it's far from trivial especially for apps that I don't have. You can help by posting traces (+server,+win,+message is usually a good start) of the offending behavior.
I just checked out cvs today, and I noticed the issue has been fixed, likely due to this patch:
http://www.winehq.org/hypermail/wine-cvs/2005/02/0422.html
Just wanted to report in to say all is working again. Thanks guys. I tried sending a trace over earlier, by the way, but spam guard blocked it every time I tried doing that.
--Nick Hornback
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Wed, 2005-02-23 at 04:20, Nick Hornback wrote:
--- Alexandre Julliard julliard@winehq.org wrote:
There is a lot of interest in fixing it, but it's far from trivial especially for apps that I don't have. You can help by posting traces (+server,+win,+message is usually a good start) of the offending behavior.
I just checked out cvs today, and I noticed the issue has been fixed, likely due to this patch:
http://www.winehq.org/hypermail/wine-cvs/2005/02/0422.html
Just wanted to report in to say all is working again. Thanks guys. I tried sending a trace over earlier, by the way, but spam guard blocked it every time I tried doing that.
--Nick Hornback
The Zoo Tycoon 1 Demo is still not working.
Alexandre, if you'd still like a trace (+server,+win,+message) I can send it to you.
Paul Vriens.
On Sat, 12 Feb 2005 09:46:19 -0800, Nick Hornback wrote:
This is because, as far as I'm aware, these applications don't send BeginPaint/EndPaint as they technically should, but they all work fine on native Windows. Now, before, it has simply been a matter of reversing the patch, no big deal. However, since the region handling has been moved to the server, that is not possible without a lot of tinkering, something that I just don't have the mad skillz to do.
To reiterate, the problem is not the lack of BeginPaint/EndPaint but rather the fact that some apps are not validating the invalid region for some reason. BeginPaint/EndPaint do this for you, but they aren't the only way (which is why Foobar2000 can get away without it).
In particular, Notes has regressed as well so I will be working on this. I might take a look at Foobar2000 as well to see if I can figure out if it's a similar problem or a different one.
Unfortunately we don't really understand what's going on here. There may be one bug, there may be *many* bugs all that cause the same behaviour. So I'm afraid it's not something that will be fixed overnight.
thanks -mike