public inbox for
help / color / mirror / Atom feed
From: Jon TURNEY <>
Subject: Re: redraw windows while  resizing/moving windows in multiwindow mode
Date: Wed, 07 Sep 2011 15:06:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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?

Volunteer Cygwin/X X Server maintainer

Unsubscribe info:
Problem reports:

  reply	other threads:[~2011-09-07 15:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-20 22:41 Oliver Schmidt
2011-09-07 15:06 ` Jon TURNEY [this message]
2011-09-08 13:09   ` Oliver Schmidt
2011-10-13 13:09     ` Jon TURNEY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).