This reverts commit 91b3f2e0e1.
revert wars part 4: the blizzard blitz!
the main point of freezing idlers here was not, in fact, to optimize, but to block an infinite loop which pegged the cpu until screensaver ended. this solution should be less issue-prone for the one person who had issues with the previous fix.
This reverts commit 3067f600ee.
revert wars! - i keep hitting problems - the one i still see is that i
come back to a machine that has blanked for a while - i launch some
app (terminology, sylpheed, chromium - doesn't matter) and no window
appears. psorcess is running. no matter how many times i launch it ...
no new process appears. this is a major bug. stopping the idler is an
optimization not a necessity.
so since this e main idler freeze/thaw i've noticed several times, i
come back to my machine after screen-off time period, i wke it up with
a mouse wiggle or keyboard press and try run terminology - no windwo
appears. i can run it all i want - it never shows up but the processes
are there. i've seen it happen to sylpheed where its fetch window
doesn't appear. i've had myserious menu edje objects on the top-left
with only a single item with no bg. i've had e even unable to restart
on ctrl+alt+end.
so i disabled the idler freeze/thaw as i suspected this is what the
root cause is, and sinc ethen the above problems stopped manifesting.
i can only conclude it's a deep and nasty bi-product of stopping the e
main idler, so don't do it. :) better be a bit less efficient than
buggy. either way setting manual rendering and dropping the animator
framerate should do almost all the things needed anyway.
normal clients rely upon the guarantee that they will receive another resize on next render when size updates occur before visibility happens, but overrides will never receive another resize since they always size accurately. by remembering that the state was previously considered dirty, render updates which occur before visibility are no longer lost until the next damage/resize occurs
tl;dr: your menus show up again
this was added a while ago to fix positioning of windows that wanted to start centered but couldn't accurately calculate xinerama screen sizes, resulting in windows getting centered across the screen split. it ended up being a bit too aggressive, however.
this option causes window activation requests to only activate a window if it is on a currently visible virtual desktop, otherwise it will be set as urgent. I recall that things may have worked this way long ago...
the main idea here is to not DRAW at the time of the first damage to avoid overdraw, but ignoring the fact that the region is ready to be drawn can be problematic when the drawing eventually occurs. best choice here is to keep the region but not the render update
reshadowing earlier than this makes it very likely that client attributes have not been fetched, meaning that the match will fall through to a default type match instead of using the correct one
Mike Blumenkrantz
Carsten Haitzler