On Wed, 29 Jan 2014 09:56:48 +0900 Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
> 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... :) Not possible; all new clients get a zone assigned immediately even if they later get moved out of it. This doesn't block new clients from being created. > > > Adding screens should have no effect since we don't automatically move > > clients to newly-added zones. > > yeah - though in future we likely will. Possible, but even then it still wouldn't be affected by this. > > > 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. What I'm saying here is that the behavior is identical. It's always going to be "the wrong screen" if there's lots of monitors since we just move everything to the first zone in all cases. Stacking is unaffected by this since it never gets deferred. I use click focus, and the situation that you described is one that I tested already and it seems to work as expected. I did find a general stacking issue with more extensive testing though, so this has been a worthwhile experiment either way. > > > > > 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(+) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ 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
