Re: redraw windows while resizing/moving windows in multiwindow mode

[Jon TURNEY <jon dot turney at dronecode dot org dot uk>]

On 20/08/2011 23:41, Oliver Schmidt wrote:
> the following patch is a quick & dirty hack to enable redrawing of windows
> while the user moves or resizes the window.
>
> This patch should be seen as experimental proof that this can be done with
> only small changes in the source code.

This is fine as a proof of concept, and it would be nice to handle this better 
and do X window updates during the Windows modal resizing loop, but I don't 
think I can apply this patch.

> The main problem with window resizing/moving under Windows is, that in the
> function invocation stack dix/Dispatch -> os/WaitForSomething -> WakeupHandler
> -> hw/xwin/winWakeupHandler -> Windows/DispatchMessage ->
> hw/xwin/winTopLevelWindowProc the Windows function DispatchMessage does not
> return while the user resizes/moves a window. This function only returns after
> the user releases the mouse button. However the dix/Dispatch functions must be
> run to allow the clients to process the queued redraw/resizing events.

Well, in fact, no X events are processed while in the modal resizing loop, so 
for e.g. if you have ico running in another X window, it stops updating while 
an xterm window is being resized.

Note that there are other modal loops in Windows message handling, I think 
moving the scrollbar also involves one (which can happen in windowed mode with 
the -scrollbar option)

> The enclosed hack simply moves the invocation of DispatchMessage in
> winWakeupHandler outside WaitForSomething into Dispatch and breaks up the
> Dispatch function into a loop and inner dispatch handling that can be called
> from the winTopLevelWindowProc while WM_SIZE/WM_MOVE events are processed.
> This could further be improved by setting a windows timer while resizing
> moving to process clients messages even if the mouse is not moved while
> resizing (and therefore WM_SIZE/WM_MOVE events are not send).
>
> What do you think about this idea? One problem here is, that the dix package
> is also affected. Of course some work must be done to cleanly integrate this
> into the existing dix/hw architecture.

I'm not sure how to structure the change to Dispatch() in a way which would be 
acceptable upstream.

An additional point to consider is that you may have introduced the 
possibility of re-entrancy into either the X window message dispatcher, or the 
Windows message dispatcher, which may not be safe. (e.g. winTopLevelProc -> 
DispatchOneStep -> (some X event processing calls a DDX function which calls 
SendMessage) -> winTopLevelProc ...)

An alternative approach would be to move the Windows message pump into a 
separate thread from the X server message dispatch.  Unfortunately, this would 
probably involve rather major changes, and careful examination of all the 
places where the window drawing code accesses internal server state to see if 
locking was needed. (I think Xquartz is structured more like that)

Alternatively, it might be worth investigating to see if it is possible to use 
a message filter set with SetWindowsHookEx(WH_MSGFILTER) to run the X window 
dispatch while Windows is in a modal loop?

--
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://x.cygwin.com/docs/
FAQ:                   http://x.cygwin.com/docs/faq/