At 12:49 PM 9/9/00 -0700, you wrote:
>"Stephane Lussier" <[EMAIL PROTECTED]> writes:
>
>> You're right about that. My code was assuming that rectWindow wasn't changed
>> yet when entering in X11DRV_WND_SetWindowPos function, which was a false
>> assumption.
>>
>> The attached patch fix the problem.
>
>XGetWindowAttributes will cause a round-trip to the server, which will
>hurt performance and may have other side effects. Couldn't we
>determine locally if the window needs to be mapped?
I think it could be done easily by adding a flag to either the pDriverData
structure or using another bit in the wnd->flags word.
I can do it if Stephane has other things to do, but I have
another question on the existing code - mostly aimed at Stephane
since he wrote it, but anyone experienced in X programming could
answer I guess.
There is this comment in the X11DRV_WND_SetWindowPos function (windows/wnd.c)
that I don't understand.
/* If the window where we should do the insert is zero-sized (not mapped)
don't used this window since it will possibly crash the X server,
use the "non zero-sized" window above */
What I find strange is that in current Wine, there is no "zero-sized'
X window. There is a hack to prevent that which is fixing the window
dimension to 1x1. So I don't see why setting the display order should
crash the server if a XRestackWindow is reordering an unmapped 1x1 window ?
In fact, I tried to remove this special-case code altogether and none of my
test apps crashes or has a regresion (IIRC I have even one working better).
So could it not be possible to simplify this code ? In its current state, it will not
make an easy job for future maintainers :-( - and I think it will be necessary
to make it more complex still for handling better z-order problems...
Gerard
