public inbox for cygwin-xfree@sourceware.org help / color / mirror / Atom feed
From: Jon TURNEY <jon.turney@dronecode.org.uk> To: cygwin-xfree@cygwin.com Cc: oschmidt-mailinglists@gmx.de Subject: Re: redraw windows while resizing/moving windows in multiwindow mode Date: Thu, 13 Oct 2011 13:09:00 -0000 [thread overview] Message-ID: <4E96E2EF.7080301@dronecode.org.uk> (raw) In-Reply-To: <4E68BE79.1030604@gmx.de> 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/
prev parent 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4E96E2EF.7080301@dronecode.org.uk \ --to=jon.turney@dronecode.org.uk \ --cc=cygwin-xfree@cygwin.com \ --cc=oschmidt-mailinglists@gmx.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe 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).