On Wed, Dec 1, 2010 at 4:52 PM, Thomas Adam <tho...@fvwm.org> wrote: > Hi -- > > On Tue, Nov 30, 2010 at 05:44:28PM -0800, Jason Weber wrote: >> On Sun, Nov 28, 2010 at 5:37 AM, Thomas Adam <tho...@fvwm.org> wrote: >> > Hi -- >> > >> > On Mon, Nov 22, 2010 at 11:44:56PM -0800, Jason Weber wrote: >> >> Screen Edge Avoidance >> >> --------------------- >> >> Screen edges now repel proxies. In reasonable situations, >> >> proxies will never be pushed off screen. >> > >> > This sounds like a bug-fix to me? Or is this so in-grained with everything >> > else. separating this out isn't possible? >> >> It probably could be separated out. The current diff is rather large, >> so it just means sifting through all that to pick out a few changes. > > Ok. Can you do that?
Yes, I should try. >> FlickeringMoveWorkaround is boolean and removes all those in-motion events. >> The ConfigureSkipLimit can just reduce the number of configure events, >> such as every sixteenth one and also whenever the event stream goes idle. > > It only removes sending repeated ConfigureNotify events (there are no other > "in-motion events" to speak of here). Why is a threshold value needed here, > and how would in interaction of such a BugOpts setting affect FvwmProxy? > This still seems very odd to me. > > Why do you think this is needed -- I mean, what problem is this solving? > > -- Thomas Adam Ok, when you move windows around, proxies (when shown) will drag along with them. Now with four walls, you have five windows to drag along instead of one. And the windows that aren't moving still need refresh more with the always-on-top proxies and walls. If you get a Configure for nearly every pixel step, that can put a heavy load of redraws in the pipe and it can even take a couple seconds of lag time to catch up even after you've stopped any movement (it seems more sluggish on my faster RedHat work machine than my home Ubuntu machine, but there are probably too many details to figure out why they are different). If I ignore all but every 16th configure, it still has fully responsive primary window motion and I get decent (adjustably stuttering) feedback for the moving walls and proxies. Essentially, if you turn on walls and you are configured to show all the proxies, then showing proxies will temporarily multiply your mapped window count for the current desk by 6. With 10 to 15 windows per desk, that number can get pretty big. Would using FlickeringMoveWorkaround mean I don't get any redraws until the move is complete? I still get all the primary window redraws which seem really quick. ConfigureSkipLimit only affects the proxy and wall windows. -- Jason Weber
