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: Wed, 07 Sep 2011 15:06:00 -0000 [thread overview] Message-ID: <4E67884E.2020900@dronecode.org.uk> (raw) In-Reply-To: <4E50380A.6070101@gmx.de> On 20/08/2011 23:41, Oliver Schmidt wrote: > the following patch is a quick & dirty hack to enable redrawing of windows > while the user moves or resizes the window. > > This patch should be seen as experimental proof that this can be done with > only small changes in the source code. This is fine as a proof of concept, and it would be nice to handle this better and do X window updates during the Windows modal resizing loop, but I don't think I can apply this patch. > The main problem with window resizing/moving under Windows is, that in the > function invocation stack dix/Dispatch -> os/WaitForSomething -> WakeupHandler > -> hw/xwin/winWakeupHandler -> Windows/DispatchMessage -> > hw/xwin/winTopLevelWindowProc the Windows function DispatchMessage does not > return while the user resizes/moves a window. This function only returns after > the user releases the mouse button. However the dix/Dispatch functions must be > run to allow the clients to process the queued redraw/resizing events. 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. 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) > The enclosed hack simply moves the invocation of DispatchMessage in > winWakeupHandler outside WaitForSomething into Dispatch and breaks up the > Dispatch function into a loop and inner dispatch handling that can be called > from the winTopLevelWindowProc while WM_SIZE/WM_MOVE events are processed. > This could further be improved by setting a windows timer while resizing > moving to process clients messages even if the mouse is not moved while > resizing (and therefore WM_SIZE/WM_MOVE events are not send). > > What do you think about this idea? One problem here is, that the dix package > is also affected. Of course some work must be done to cleanly integrate this > into the existing dix/hw architecture. I'm not sure how to structure the change to Dispatch() in a way which would be acceptable upstream. 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 ...) 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 all the places where the window drawing code accesses internal server state to see if locking was needed. (I think Xquartz is structured more like that) 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? -- 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/
next prev parent reply other threads:[~2011-09-07 15:06 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 [this message] 2011-09-08 13:09 ` Oliver Schmidt 2011-10-13 13:09 ` Jon TURNEY
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=4E67884E.2020900@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).