Hmmm, as a follow up, changing
if ((flags & DCX_CLIPCHILDREN) && (mode != ClipByChildren))
to
if (flags & DCX_CLIPCHILDREN)
in get_visible_region fixes it. I assume altering the assignment in GetDC would have the same effect.
I think this is what you were talking about earlier with Wine vs X11 clipping.... it seems in this case leaving it up to X doesn't work. I don't understand enough about this area to submit a proper patch though, so I just thought I'd let you know what change fixed the problem.
thanks -mike
On Fri, 2003-05-16 at 16:10, Mike Hearn wrote:
Yes I know what you talking about. Here is a patch for this. When I presented it to Alexandre a while ago he said that it's not necessary because X will take care of the clipping for us. He said we don't need to do it.
Thanks for the patch. I applied it, but other than the Google "I'm feeling lucky" buttons now appearing when i mouse over them, not much changed (clip_children is being called now though).
Here's an excerpt from a trace:
trace:x11drv:X11DRV_Expose win 0x10025 (4000009) 227,463 365x91 trace:x11drv:X11DRV_Expose win 0x1002d (400002a) 227,0 365x40 trace:x11drv:X11DRV_CreateBitmap (0xc18) 365x91 24 bpp trace:x11drv:X11DRV_GetDC visible=1 trace:x11drv:clip_children called for parent=1002d, last=0 trace:x11drv:get_visible_region top=0x1002a, win->hwndSelf=0x1002d trace:x11drv:get_visible_region WS_CLIPSIBLINGS for child trace:x11drv:clip_children called for parent=1002a, last=1002d trace:x11drv:clip_children one trace:x11drv:clip_children two trace:x11drv:get_visible_region WS_CLIPSIBLINGS for child trace:x11drv:clip_children called for parent=10029, last=1002a trace:x11drv:clip_children one trace:x11drv:clip_children two
And the window tree looks like this:
10025 (main window - java renders buttons etc direct to it) |-10029 (start of IE embedding?) |- 1002A |- 1002D (this seems to be the IE rendering area) |-10026 (not sure what this is)
So, As you can see Expose events are sent to the main window and the embedded IE window, which makes sense. I can see the clip_children call seemingly chaining up the window tree - it starts at 1002D and ends up at 10029 near the top, BUT for some reason clip_children is never called with a parent of 10025.
I'm pretty lost in this code, I'm not sure how Java is even drawing - I switched off the blitting code and it mangled most Wine graphics in other apps, but Java was just like normal. But I think maybe clip_children should be called for the top level window?
thanks a lot for you help Ulrich, it's appreciated! -mike
Hmmm that's not right. It makes me suspect even more that it's a z-order issue. Perhaps over the weekend I'll take a stab at it.
/Ulrich
On Fri, 2003-05-16 at 11:51, Mike Hearn wrote:
Hmmm, as a follow up, changing
if ((flags & DCX_CLIPCHILDREN) && (mode != ClipByChildren))
to
if (flags & DCX_CLIPCHILDREN)
in get_visible_region fixes it. I assume altering the assignment in GetDC would have the same effect.
I think this is what you were talking about earlier with Wine vs X11 clipping.... it seems in this case leaving it up to X doesn't work. I don't understand enough about this area to submit a proper patch though, so I just thought I'd let you know what change fixed the problem.
thanks -mike
Unfortunately it seems this "fix" did not fix my app at all, only the test case. Any other tips you might have on where the bug might be would be most appreciated.
thanks -mike
On Fri, 2003-05-16 at 18:08, Ulrich Czekalla wrote:
Hmmm that's not right. It makes me suspect even more that it's a z-order issue. Perhaps over the weekend I'll take a stab at it.
/Ulrich
On Fri, 2003-05-16 at 11:51, Mike Hearn wrote:
Hmmm, as a follow up, changing
if ((flags & DCX_CLIPCHILDREN) && (mode != ClipByChildren))
to
if (flags & DCX_CLIPCHILDREN)
in get_visible_region fixes it. I assume altering the assignment in GetDC would have the same effect.
I think this is what you were talking about earlier with Wine vs X11 clipping.... it seems in this case leaving it up to X doesn't work. I don't understand enough about this area to submit a proper patch though, so I just thought I'd let you know what change fixed the problem.
thanks -mike
Oh, I should probably have noted that expose events are processed properly - forcing a repaint of an area, by dragging a window over it for instance, and IE will display that area properly. It's only on certain WM operations, like switching desktops, initial map, changing stacking order (for some reason this app forces the window to the bottom then back to the top while loading a page). So, I suppose I'm wondering if Z-Order bugs would interfere with the ExposeEvent->WM_PAINT dispatch system?
On Mon, 2003-05-19 at 12:12, Mike Hearn wrote:
Unfortunately it seems this "fix" did not fix my app at all, only the test case. Any other tips you might have on where the bug might be would be most appreciated.
thanks -mike
On Fri, 2003-05-16 at 18:08, Ulrich Czekalla wrote:
Hmmm that's not right. It makes me suspect even more that it's a z-order issue. Perhaps over the weekend I'll take a stab at it.
/Ulrich
On Fri, 2003-05-16 at 11:51, Mike Hearn wrote:
Hmmm, as a follow up, changing
if ((flags & DCX_CLIPCHILDREN) && (mode != ClipByChildren))
to
if (flags & DCX_CLIPCHILDREN)
in get_visible_region fixes it. I assume altering the assignment in GetDC would have the same effect.
I think this is what you were talking about earlier with Wine vs X11 clipping.... it seems in this case leaving it up to X doesn't work. I don't understand enough about this area to submit a proper patch though, so I just thought I'd let you know what change fixed the problem.
thanks -mike
On Mon, 2003-05-19 at 11:52, Mike Hearn wrote:
Oh, I should probably have noted that expose events are processed properly - forcing a repaint of an area, by dragging a window over it for instance, and IE will display that area properly. It's only on certain WM operations, like switching desktops, initial map, changing stacking order (for some reason this app forces the window to the bottom then back to the top while loading a page). So, I suppose I'm wondering if Z-Order bugs would interfere with the ExposeEvent->WM_PAINT dispatch system?
It would interfere with the order in which the controls are painted. It looks like Alexandre committed some z-order and painting related patches. Could you give the latest CVS tip a try?
/Ulrich
It would interfere with the order in which the controls are painted. It looks like Alexandre committed some z-order and painting related patches. Could you give the latest CVS tip a try?
I already did - unfortunately it seems CVS head has caused so many regrsesions in my app I cannot get to the faulty part of the code anymore, it crashes before I get there.
I applied this one (http://www.winehq.org/hypermail/wine-cvs/2003/05/0259.html) to the tree I was originally working from, which is now probably about 2 months out of date, but it appeared to make no difference (except the window now no longer moves from top to bottom and top again in the z-order).
Were there others it needed/depended on? Or other z-order fixes?
I'm trying to track down how Java does graphics rendering, as disabling all blitting operations kills IE just fine, but Java somehow survives. The Java code base is huge but pretty clean and well written, with lots of good comments.
thanks -mike
It would interfere with the order in which the controls are painted. It looks like Alexandre committed some z-order and painting related patches. Could you give the latest CVS tip a try?
Random thoughts...
* Java appears to create two child windows of the main window in this case, one for rendering Swing (the canvas) and the other is the shell embedding window for IE
* Spy++ in Windows shows two differences with Wine:
1) WS_CLIPSIBLINGS is set on the top level window in Windows, but not Wine. However, forcing WS_CLIPSIBLINGS in CreateWindowEx doesn't appear to make any difference. Presumably as it's a top level window, this flag makes no difference either way.
2) The windows appear in a different order in the windows tree that Spy++ gives you. In Wine, the IE embedding window appears as the first child, in Windows it appears as the last (I'm running Spy++ under Wine to see this). The positions of the AWT/Swing rendering window and the shell embedding window are reversed in other words.
I think it's the two child windows fighting, not the parent and child as I originally thought.... unfortunately MSDN doesn't seem to be clear on how z-order for child windows works. As both child windows have WS_CLIPSIBLINGS but one appears to be entirely overlapped by the other, it's not obvious to me how this situation should be handled, the smaller window would probably have its output entirely clipped, regardless of z-order?
It's also not obvious how Spy++ decides what order to put windows in the tree heirarchy, it's probably based on z-order.
</random thoughts>
thanks for your insights -mike
Hi Ulrich,
I made a much simpler test case. All you need to do is edit the run script to point to wherever you extracted the test case to. It is only one file, all you need to do is install the Sun JDK to c:\java
It creates a Swing JFrame and adds a Swing Button and an AWT button. Switching virtual desktops makes the button disappear, forcing a repaint of that area makes it reappear.
If you, or anybody else, could take a look, that'd be most appreciated. thanks -mike
On Tue, 2003-05-20 at 12:38, Ulrich Czekalla wrote:
On Mon, 2003-05-19 at 11:52, Mike Hearn wrote:
Oh, I should probably have noted that expose events are processed properly - forcing a repaint of an area, by dragging a window over it for instance, and IE will display that area properly. It's only on certain WM operations, like switching desktops, initial map, changing stacking order (for some reason this app forces the window to the bottom then back to the top while loading a page). So, I suppose I'm wondering if Z-Order bugs would interfere with the ExposeEvent->WM_PAINT dispatch system?
It would interfere with the order in which the controls are painted. It looks like Alexandre committed some z-order and painting related patches. Could you give the latest CVS tip a try?
/Ulrich
-
Mike Hearn -
Ulrich Czekalla