Hi Jon,
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. 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. 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).
Best regards,
Oliver
--
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/
