Changes to multiwindow mode and always-on-top (ping Takuma)

[Earle F. Philhower III]

Howdy,

At 02:05 AM 3/19/2004 -0500, Harold wrote:
>Yup, Takuma knew there were bugs, but the new code is so much more 
>efficient (the old code was performing lots of operations during our block 
>and wakeup handlers, which get called hundreds of times per second) that I 
>told him to leave it there for a few weeks until we could figure out if we 
>could fix it and keep the performance improvement.

Yes, it's way faster than before with his changes, but sometimes it
seems to have optimized too many screen updates.  These only seem to
be occasional glitches, and forcing a redraw of the window always
clears things up (except for the stacking order stuff).

I fixed things up the straightforward way:  When a WM_RAISE or
WM_MAP event filters to us, I start with the mapped window, xvert it
to the HWND, and work a way through Win32 space up to the top of the
Z order.  Any window that's still above the HWND we just XRaise()ed, I
XRaise the XWindow of that HWND.  AFAICT this will only occur with AOT
windows, and should result in 0 work at all if there aren't any AOTs...

>Hmm... if you have it mostly fixed, then check it in... Takuma is 
>currently burning cycles trying to fix this also but I don't think he has 
>gotten far.  I think he will appreciate having a little help :)

All I've really fixed, AFAIK, is the case where the X and W32 stack
order aren't the same...I doubt this is what he's having trouble with,
it's too simple.

>>If I put this flag and behavior back I can get things working
>>100% AFAICT:  a-o-t windows minimized from the taskbar, the
>>system menu, or the button disappear.
>That sounds good.  Takuma was talking about re-adding the fRestacking 
>flag... is that the flag you are talking about?

No, unfortunately this is just a bit for the HWND_TOPMOST state of
the window when it's minimized.  Without clearing the TOPMOST state in
W32, the window technically "stay on top" of other windows since
a SIZE_MINIMIZE is handled by an ignored MOVE (-32000,-32000) IIRC.
Regular apps don't care since they always have a consistent view of
a window's position, but in this case we have X which thinks the
window is still at (x,y) and Windoze which has it as (-32k,-32k)...

[5 minutes later...]
 > This just in: Takuma said go ahead and commit both fixes so he can
 > review them.  He says he will be able to respond sometime after four
 > hours.  (He is in #cygwinx on irc.freenode.net now.)

OK, it is checked in (sorry if no xorg-commit mail, I think my
pdx.freedesktop.org CVS account has a real name that's not valid...)

-Earle F. Philhower, III
  earle@ziplabel.com
  cdrlabel - ZipLabel - FlpLabel
  http://www.cdrlabel.com