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

On 08/09/2011 14:09, Oliver Schmidt wrote:
> On 9/7/2011 5:05 PM, Jon TURNEY wrote:
>> This is fine as a proof of concept, and it would be nice to handle this
> did you try the patch? It looks&  feels very smooth if you resize a
> xlock and the xclock and all x11 background windows are redrawn while
> resizing ;-)
>> better and do X window updates during the Windows modal resizing loop,
>> but I don't think I can apply this patch.
> but I hope this patch can be used as a starting point.
>> 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.
> with the patch X events are processed. With the patch, ico redraws also
> while windows are moved or resized, as long as the mouse is moved. For
> display updating without moving the mouse while modal resizing/moving is
> in progress, I already mentioned the timer event that is possible to
> improve the patch.
> Thanks for mentioning "ico", I didn't know this program, it is an
> interesting experimental tool: it shows that the patch is too
> aggressive, i.e. the ui interface is not responsive, perhaps due to my
> "critical" code fragment:
> 	while (DispatchOneStep(FALSE)>  0) {}
> So I will try now to improve the patch for better responsiveness.
>> 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)
> One could introduce a similar patch there too ;-) However a patch for
> scrollbar option in windowed mode is not as reasonable as in multiwindow
> mode, because the static redrawing of the x server makes sense in
> windowed mode.

I'm not sure I follow your reasoning here.  If we have 'ico' running in 
windowed mode, why should it stop updating while the scrollbars are being moved?

> Only in multiwindow mode the redrawing is strange, e.g.
> if you applied my patch "minimize redraw events after resizing/moving
> windows in multiwindow mode", you will see other X11 background windows
> while "resizing" a x11 foreground window in the window that is resized,
> because actually the x11 window is not resized due to missing x11 event
> processing, but the xserver simply redraws all x11 windows in the
> current size. In windowed mode, no x11 window is resized.
>> I'm not sure how to structure the change to Dispatch() in a way which
>> would be acceptable upstream.
> I hoped, you had an idea. What are the criteria to be accepted upstream?
> At least the patch introduces only a "bypass", i.e. existing code/usage
> is not affected. It would be discouraging if no upstream changes are
> possible to improve the cygwin x server's multi window mode, since this
> is the mode that allows the highest integration of x11 applications with
> native windows programs. If no upstream changes are possible one
> fallback could be to have a local patch (or #ifdef switch) for the
> cygwin x server.
>> 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 ...)
> Could you explaind this more explicitly? How can this be tested?

> As I understood the code, the function "Dispatch" is only called once
> per x server invocation. And the new function "DispatchOneStep" is meant
> to be processed re-entrant.

I don't see how you can guarantee that all the X server code which 
DispatchOneStep() might call is re-entrant?

I cannot rid myself the suspicion this may happen (since there are now code 
paths winTopLevelProc->DispatchOneStep and DispatchOneStep->winTopLevelProc)

> This is why the boolean parameter
> handleWindowMessage is introduced and why I had to remove the invocation
> of DispatchMessage out of the winWakeupHandler which is called in
> WaitForSomething.

>> 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
> I agree that this would cause a lot of more work than the approach of my
> patch. I'm not sure if moving the Windows message handling into a
> different thread will solve the problem totally: there still is the
> problem, that in the modal windows event loop the x11 event processing
> must be invoked. At least one has to totally decouple the x11 and
> Windows event processing, but then still in the modal event loop the now
> decoupled x11 processing must be triggered. So it seems to me, that
> decoupling the x11 and Windows processing does only prevent upstream
> changes but does not solve the problem, that in the modal Windows event
> loop small progressing parts for X11 (coupled or decoupled) have to be done.
>> 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?
> I'm not sure if I'm understanding this approach correctly, but I think
> even with SetWindowsHookEx we still have the problem, that the main loop
> in Dispatch has to be broken into smaller parts that can be invoked from
> inside the modal Windows event loop (or hook).

Yes, I think you are correct.  A hook has the advantage that X event dispatch 
will continue to occur during all the modal event loops that Windows has, 
rather than just the ones we have noticed :-)

Volunteer Cygwin/X X Server maintainer

Unsubscribe info:
Problem reports:

      reply	other threads:[~2011-10-13 13:09 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
2011-09-08 13:09   ` Oliver Schmidt
2011-10-13 13:09     ` Jon TURNEY [this message]

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).