From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10643 invoked by alias); 13 Oct 2011 13:09:23 -0000 Received: (qmail 10414 invoked by uid 22791); 13 Oct 2011 13:09:22 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from smtpout.karoo.kcom.com (HELO smtpout.karoo.kcom.com) (212.50.160.34) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 13 Oct 2011 13:09:02 +0000 Received: from 213-152-38-55.dsl.eclipse.net.uk (HELO [192.168.0.5]) ([213.152.38.55]) by smtpout.karoo.kcom.com with ESMTP; 13 Oct 2011 14:08:59 +0100 Message-ID: <4E96E2EF.7080301@dronecode.org.uk> Date: Thu, 13 Oct 2011 13:09:00 -0000 From: Jon TURNEY Reply-To: cygwin-xfree User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20110929 Thunderbird/8.0 MIME-Version: 1.0 To: cygwin-xfree@cygwin.com CC: oschmidt-mailinglists@gmx.de Subject: Re: redraw windows while resizing/moving windows in multiwindow mode References: <4E50380A.6070101@gmx.de> <4E67884E.2020900@dronecode.org.uk> <4E68BE79.1030604@gmx.de> In-Reply-To: <4E68BE79.1030604@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Reply-To: cygwin-xfree@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com X-SW-Source: 2011-10/txt/msg00024.txt.bz2 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/