Hello!
I've made a patch for http://bugs.winehq.org/show_bug.cgi?id=640
I'm sending it here because I don't 100% sure it's ready for wine-patches. But the patch fixes an important problem and I don't want it to be unnoticed.
On certain versions of XFree86 (4.2.1 + Raveon 7000/VE), focus rectangles are painted in white. Also, windows with thin frames (including all popup windows) create mess when dragged, except in when managed mode.
It appears that GXxor value used in graphics/x11drv/graphics.c is misinterpreted - instead of xoring the background with the pen color, the pen color is painted as is. Another xoring doesn't hide the rectangle, thus creating mess of white dotted rectangles.
The radical fix would be to avoid GXxor completely, but I'm leaving it to gurus and I'm not sure if it's needed. Fortunately, there is a correct and justifiable fix on the higher level.
The focus rectangle (e.g. the rectangle around active buttons) should be painted using the system text color. Xoring this color with background is wrong. Even on systems where it works, it changes the color from black to dark gray (light gray xor white), although not too much to notice it. DrawFocusRect() has been changed to use R2_COPYPEN mode.
On the other hand, draw_moving_frame() should use xor, so using DrawFocusRect() is wrong there, once the later is fixed. PatBlt() with PATINVERT works just fine with buggy XFree86 and it's already used for thick frames. The patch uses a checkered brush to imitate the dotted line.
The result is very close to what I see on Windows 2000 - dotted line of one pixel wide using inverted color. In fact, the frame seems to be redrawn faster and smoother than without the patch on the system without the bug.
Pavel Roskin proski@gnu.org writes:
The focus rectangle (e.g. the rectangle around active buttons) should be painted using the system text color. Xoring this color with background is wrong. Even on systems where it works, it changes the color from black to dark gray (light gray xor white), although not too much to notice it. DrawFocusRect() has been changed to use R2_COPYPEN mode.
I don't think that's correct. MSDN explicitly states that DrawFocusRect uses XOR, so that you can use it a second time to remove the rectangle.
On Thu, 25 Sep 2003, Alexandre Julliard wrote:
Pavel Roskin proski@gnu.org writes:
The focus rectangle (e.g. the rectangle around active buttons) should be painted using the system text color. Xoring this color with background is wrong. Even on systems where it works, it changes the color from black to dark gray (light gray xor white), although not too much to notice it. DrawFocusRect() has been changed to use R2_COPYPEN mode.
I don't think that's correct. MSDN explicitly states that DrawFocusRect uses XOR, so that you can use it a second time to remove the rectangle.
OK, drop that part of the patch for now. I think that xoring anything with COLOR_WINDOWTEXT is incorrect, but I need to test possible other solutions.
After all, the bug is about the white mess from dragging windows, which is a bigger problem.
I've tested the patch on the system without the bug (XFree86 4.3.0, ATI Rage 128), and the patch doesn't change anything, which is good.
We probably need another program to test GDI functions. Ideally, screenshots from Wine an Windows should match to the pixel.
Pavel Roskin proski@gnu.org writes:
OK, drop that part of the patch for now. I think that xoring anything with COLOR_WINDOWTEXT is incorrect, but I need to test possible other solutions.
After all, the bug is about the white mess from dragging windows, which is a bigger problem.
Well, yes, but it's a bug in XFree86, not in Wine.
On Thu, 25 Sep 2003, Alexandre Julliard wrote:
Pavel Roskin proski@gnu.org writes:
OK, drop that part of the patch for now. I think that xoring anything with COLOR_WINDOWTEXT is incorrect, but I need to test possible other solutions.
After all, the bug is about the white mess from dragging windows, which is a bigger problem.
Well, yes, but it's a bug in XFree86, not in Wine.
Confirmed. Accelerated X works correctly with the same hardware and X libraries, while XFree86 4.2.1 exhibits the bug.
Nevertheless, I checked how the focus rectangle works on Windows 2000 and found something we may want to fix.
Actually, there are two focus rectangles. The one displayed on buttons with keyboard focus is drawn by opaque pen in xor mode using alternating button face and button text colors. This guarantees that the focus is visible if the text on buttons is visible. Usually it's not different from the other focus rectangle. But if the button text is white on lightgray, the focus rectangle is almost a continuous line. If the button text is blue on lightgray, the focus rectangle is drawn by yellow and black dots.
The other focus rectangle is displayed by calling DrawFocusRectangle(). In this case, the line is transparent and uses simple inversion. No color scheme settings affect the color.
I'm attaching a patch that fixes DrawFocusRectangle() to use inversion. I also removed reference to COLOR_WINDOWTEXT to aesthetic reasons. The pen color is unused, but nobody should think that any color schemes affect this function.
This change is also sufficient to work around the XFree86 bug. We don't have to work it around, but we are lucky that it's a side effect of making DrawFocusRect() correct.
I also included a patch that removes special treatment for R2_XORPEN with black pen. I don't see such behavior in Windows 2000. I also tested Paintbrush from Windows 3.11 and it has no graphical problems except Pick->Tilt, which is unaffected by this code. It's an old hack that is wrong and unneeded now.
Pavel Roskin proski@gnu.org writes:
I also included a patch that removes special treatment for R2_XORPEN with black pen. I don't see such behavior in Windows 2000. I also tested Paintbrush from Windows 3.11 and it has no graphical problems except Pick->Tilt, which is unaffected by this code. It's an old hack that is wrong and unneeded now.
Have you tried on an 8-bit display? That's where the hack is needed, and I see no evidence that this has changed. Besides it shouldn't hurt on more modern displays so I'm not sure why you want to remove it.
On Fri, 26 Sep 2003, Alexandre Julliard wrote:
Pavel Roskin proski@gnu.org writes:
I also included a patch that removes special treatment for R2_XORPEN with black pen. I don't see such behavior in Windows 2000. I also tested Paintbrush from Windows 3.11 and it has no graphical problems except Pick->Tilt, which is unaffected by this code. It's an old hack that is wrong and unneeded now.
Have you tried on an 8-bit display? That's where the hack is needed, and I see no evidence that this has changed. Besides it shouldn't hurt on more modern displays so I'm not sure why you want to remove it.
I've retested paintbrush on the 8-but display and I see no difference.
The reasons are:
1) I invested time into testing XOR operations on Windows 2000 and found no magic interpretation for the black pen. It's invisible in Windows.
2) DrawFocusRect() is Wine uses this hack accidentally. COLOR_WINDOWTEXT is black, so it becomes white. It's confusing. Not only window text is irrelevant, but Wine also gets it as black but uses as white.
3) Black pen, white background, pattern, opaque mode. The background would still be changing the image. If we consider the pen white, the pattern would be lost. I actually didn't test it, but I expect it to be broken.
Pavel Roskin proski@gnu.org writes:
I've retested paintbrush on the 8-but display and I see no difference.
The reasons are:
- I invested time into testing XOR operations on Windows 2000 and found
no magic interpretation for the black pen. It's invisible in Windows.
Well yes, that's the point, it's invisible so apps are not going to use it. On Windows black is always pixel 0, so xoring with black never does anything; if you want to invert an area you have to use white. On X, sometimes white is pixel 0, so you'd have to use black to invert; but of course Windows apps don't do that, which is why we have that hack.
- DrawFocusRect() is Wine uses this hack accidentally. COLOR_WINDOWTEXT
is black, so it becomes white. It's confusing. Not only window text is irrelevant, but Wine also gets it as black but uses as white.
That's a bug, but the bug is not that XOR changes black to white, the bug is using black with XOR in the first place (which is what your other change is correctly fixing).
- Black pen, white background, pattern, opaque mode. The background
would still be changing the image. If we consider the pen white, the pattern would be lost. I actually didn't test it, but I expect it to be broken.
I don't see how a XOR with 0 would ever change anything.
On Sat, 27 Sep 2003, Alexandre Julliard wrote:
- Black pen, white background, pattern, opaque mode. The background
would still be changing the image. If we consider the pen white, the pattern would be lost. I actually didn't test it, but I expect it to be broken.
I don't see how a XOR with 0 would ever change anything.
You will have XOR with background. Look here: http://www.red-bean.com/~proski/wine/
Patch for cmdlgtst.c to produce those pictures is attached. before.png was taken with current Wine. after.png is with the fix that removes the special procession of R2_XORPEN. I would not say that nobody will use this effect. Anyway, the whole thing is not worth arguing about.
Pavel Roskin proski@gnu.org writes:
Patch for cmdlgtst.c to produce those pictures is attached. before.png was taken with current Wine. after.png is with the fix that removes the special procession of R2_XORPEN. I would not say that nobody will use this effect. Anyway, the whole thing is not worth arguing about.
I think it's definitely worth arguing about, and you are right that there are cases where the hack is wrong, I missed the opaque background issue. Still, the hack was added for a reason, so I don't think we want to remove it completely; but it should be improved to check for the pen and background types.
On Sun, 28 Sep 2003, Alexandre Julliard wrote:
Pavel Roskin proski@gnu.org writes:
Patch for cmdlgtst.c to produce those pictures is attached. before.png was taken with current Wine. after.png is with the fix that removes the special procession of R2_XORPEN. I would not say that nobody will use this effect. Anyway, the whole thing is not worth arguing about.
I think it's definitely worth arguing about, and you are right that there are cases where the hack is wrong, I missed the opaque background issue. Still, the hack was added for a reason, so I don't think we want to remove it completely; but it should be improved to check for the pen and background types.
Too bad I cannot reproduce any problem with Paintbrush. I even put FIXME to the code but it's never activated if DrawFocusRect() is fixed (see patch).
I have no idea what "rubber-drawings" mean. I have tried all tools in 8 and 24 bpp and the problems I see are not affected by the code in question. The problems are:
Paintbrush won't exit without saving.
Flood fill takes a wrong point as reference and paints with the same incorrect offset. The horizontal offset (63) is almost equal to the width of the toolbox (64). The vertical offset is 3 pixels high. http://www.red-bean.com/~proski/wine/pbrush.png
One-color eraser (left, third from top) is a terrible CPU hog.
Selection lines are not redrawn after being covered by the menu. After the selection is canceled, the obscured part becomes visible and remains in the picture.
Saving images crashes with: Unhandled exception: unimplemented function olesvr.dll.OLERENAMESERVERDOC called in 32-bit code (0x413b6250).
What Paintbrush are you using ? Im using winme's and got no such problem when saving images (no natives are used except mfc42and mfc42loc)
But I have another big problem : if anything is modified, the whole image becomes a black square when saved.
Paintbrush won't exit without saving.
Saving images crashes with: Unhandled exception: unimplemented function olesvr.dll.OLERENAMESERVERDOC called in 32-bit code (0x413b6250).
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels
"What if tomorrow the War could be over ?" Morpheus, in "Reloaded".
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
On Tue, 30 Sep 2003, [iso-8859-1] Sylvain Petreolle wrote:
What Paintbrush are you using ? Im using winme's and got no such problem when saving images (no natives are used except mfc42and mfc42loc)
I don't know about Windows ME, but Windows 98 doesn't have Paintbrush. pbrush.exe simply calls mspaint.exe. mspaint.exe (Microsoft Paint) is a different program. Since you are mentioned mfc42, I'm assuming that you actually mean Microsoft Paint.
But I have another big problem : if anything is modified, the whole image becomes a black square when saved.
Yes, I confirm it. Also, the release of the right mouse button is not reported. But it still works much better than Paintbrush.
Anyway, I have tested Microsoft Paint in 8-bit color and I don't see the Paintbrush hack being used.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alexandre Julliard julliard-at-winehq.org |Wine Mailing Lists| wrote: | Pavel Roskin proski@gnu.org writes: | | |>OK, drop that part of the patch for now. I think that xoring anything |>with COLOR_WINDOWTEXT is incorrect, but I need to test possible other |>solutions. |> |>After all, the bug is about the white mess from dragging windows, which is |>a bigger problem. | | | Well, yes, but it's a bug in XFree86, not in Wine. |
Interesting.
Could someone point me at some refernces to these bugs in Wine and XFree86, especially Wine, because I can't find any references to them.
I see quit a lot of these, I'd like to know to what extent I've been blaming Wine unfairly for these problems ;-)
Bye -Rob.
On September 25, 2003 02:54 pm, Pavel Roskin wrote:
We probably need another program to test GDI functions. Ideally, screenshots from Wine an Windows should match to the pixel.
That will be a lot of wasted time for no good reason. I don't think we need, or that is advisable to have pixel-for-pixel compatibility of the interface.
-
Alexandre Julliard -
Dimitrie O. Paun -
Pavel Roskin -
Robert North -
Sylvain Petreolle