On Tue, 28 Jan 2014 19:38:24 -0500 Michael Blumenkrantz <michael.blumenkra...@gmail.com> said:
> On Wed, 29 Jan 2014 09:29:34 +0900 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > On Tue, 28 Jan 2014 19:26:06 -0500 Michael Blumenkrantz > > <michael.blumenkra...@gmail.com> said: > > > > > On Wed, 29 Jan 2014 09:12:18 +0900 > > > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > > > > > On Tue, 28 Jan 2014 18:54:27 -0500 Michael Blumenkrantz > > > > <michael.blumenkra...@gmail.com> said: > > > > > > > > > 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. > > > > > > > > focus is still done in the idler before in e_client, as are internal > > > > ecore-evas windows resized there. the zone is changed/set there too > > > > based on geometry changes, placement of new windows is done there > > > > too... (what happens if someone opens a new window while screensaver is > > > > on?) the client hooks used by tiling/illume etc. are called there > > > > too... :) i smell you'll have a series of buglets there. > > > > > > All of these things still happen, just not until the screen wakes up. New > > > windows were, in fact, the entire reason for adding this. As proof, if you > > > blank your screen and open a new window (or several) on a timer, you'll > > > actually see the focus animation(s) play just as your screen wakes up, and > > > focus will be set on the new window. > > > > hint - have you tried plugging in/unplugging a monitor while screensaver is > > on? since app isnt assigned to a zone yet.. what happens? e is meant to > > handle a monitor removal by shuffling apps that were on that screen to the > > current one. what if you ssh in while screen is blanked and xrandr > > add/remove screens? > > My cables are in the mail so I can't test this yet, but according to the > current code any application on a zone which is being removed gets > automatically moved (both in struct and actual position) to the first zone. > This does not occur on an idler. no - not that... these windows may not have zones assigned yet as they are being held in stasis... :) > Adding screens should have no effect since we don't automatically move > clients to newly-added zones. yeah - though in future we likely will. > At worst, it seems like maybe a window would fail to maximize/unmaximize on > the canvas until the screen woke up. or it may end up on the wrong screen? stacking order broken? eg open window a, then b then c. with click-to-focus i expect c to be on top normally with c having the focus.... just saying. lots of cases to check since normal operation is suspended, not just rendering/animation. > > > As I said, I didn't originally mean for this to go in yet since I wanted > > > to test it more, but I've had it running for a couple days without > > > noticing any issues yet, so some wider testing can't hurt. At worst I > > > roll it back for tinkering. > > > > > > > > > > > what is probably MORE useful is to do the manual rendering AND drop > > > > ecore animator frametime/rate to something very low like 1fps or > > > > 0.25fps or something (set frametime to 1.0, 4.0 or more), and on screen > > > > wakeup set it back to where ti was. :) > > > > > > That can happen too. > > > > > > > > > > > > > > > > > > > > > > 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(+) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- ------------- 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
