On Wed, 29 Jan 2014 08:46:50 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> On Tue, 28 Jan 2014 18:34:20 -0500 Michael Blumenkrantz > <michael.blumenkra...@gmail.com> said: > > > On Wed, 29 Jan 2014 08:18:20 +0900 > > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > > > On Tue, 28 Jan 2014 11:29:16 -0500 Michael Blumenkrantz > > > <michael.blumenkra...@gmail.com> said: > > > > > > if you're going to do this... > > > > > > 1. double-check _e_main_cb_idle_before + _e_main_cb_idle_after - notice an > > > edje freeze/thaw. by removing these you may be stuck in a edje freeze > > > state... you should now track this since e was freezing/thawing every time > > > it comes out of idle and goes back - so depending where this is called... > > > it may leave you in a freeze. > > > > I looked at these and had checks for it initially, but I removed them > > because > > I'm not sure how that could occur since it's only called from > > screensaver-related stuff which should only be called outside of idler > > processing. > > but it could be called within the idler time (i know e_dbus and eldbus use > idlers). so that means if this was used from something triggered by a dbus msg > it COULd possibly be called there. that's why i'm saying - you want to be > careful and ensure you keep things in a controlled state. :) I guess that's possible. > > > > 2. what is probably far more useful is to se the comp canvas(es) to manual > > > render - ecore_evas_manual_render_set(ee, EINA_TRUE/FALSE) - this > > > basically > > > stops the "always render automatically when you go idle" and makes > > > rendering > > > only happen when you explicitly call ecore_evas_manual_render(ee). in fact > > > this is far more useful than playing with the e main idlers as when > > > ascreen is blanked its output isn't visible so there is no point > > > rendering, > > > BUT... the main idlers do things other than render - they make e respond > > > to > > > icccm and events and actually DO the thing requested - at a logical level, > > > so stopping this may lead to lots of unexpected consequences. > > > > Manual rendering would probably be useful in addition to, but not instead > > of, > > stopping the idlers; I already blocked render updates from occurring during > > screensaver a while ago before the E19 merge, so this would only stop things > > like animating gadgets from continuing to animate. The intent was precisely > > to stop clients from updating themselves since this can, in many cases, lead > > to infinite loops when a client tries to perform some X action which can't > > occur due to the display being off (or so my testing has shown). The only > > property which gets set on clients that should affect anything during > > screensaver would be the urgency hint, and this no longer relies on an idler > > to set itself. > > imagine this - a client requests a move of its window. or a resize... and then > we respond saying "ok - good. moved here. resized t this". but the window will > never actually do that... because its an idle enterer -> > e_client_idler_before. > now we respond saying ok - size/position changed. sure- there may be a > race/lag > until it's done, but this lag becomes seconds minutes, hours... days... and > the > app may then query actual location and find it is not where we said it would > be. this can lead to all sorts of behavioral problems depending on how the > clients themselves work and behave. These requests should still execute as expected since they come directly from X handlers, and so they would fall right through to the expected outcome of performing the resize but without doing any non-instant canvas operations. > > > > > Wasn't intending to put this in just yet, but I guess we can try it out. > > > > If anyone notices any rendering issues upon waking the screen up then > > > > this is why. > > > > > > > > On Mon, 27 Jan 2014 18:50:05 -0800 > > > > Mike Blumenkrantz <michael.blumenkra...@gmail.com> wrote: > > > > > > > > > discomfitor pushed a commit to branch master. > > > > > > > > > > http://git.enlightenment.org/core/enlightenment.git/commit/?id=55bc44c9b853d52e6a1053342c4962c3093bc632 > > > > > > > > > > commit 55bc44c9b853d52e6a1053342c4962c3093bc632 > > > > > Author: Mike Blumenkrantz <zm...@samsung.com> > > > > > Date: Mon Jan 27 16:16:41 2014 -0500 > > > > > > > > > > feature: main idlers now freeze during screensaver to conserve > > > > > power > > > > > --- > > > > > src/bin/e.h | 2 ++ > > > > > src/bin/e_comp.c | 2 ++ > > > > > src/bin/e_comp_canvas.c | 10 ++++++++++ > > > > > src/bin/e_main.c | 18 ++++++++++++++++++ > > > > > 4 files changed, 32 insertions(+) > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > WatchGuard Dimension instantly turns raw network data into actionable > > > > security intelligence. It gives you real-time visual feedback on key > > > > security issues and trends. Skip the complicated setup - simply import > > > > a virtual appliance and go from zero to informed in seconds. > > > > http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk > > > > _______________________________________________ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > > ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
