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. :) > > 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. > > > 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 > > > > > > > > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
