redraw windows while resizing/moving windows in multiwindow mode

[Jon TURNEY]

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

-- 
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/