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. Adding screens should have no effect since we don't automatically move clients to newly-added zones. At worst, it seems like maybe a window would fail to maximize/unmaximize on the canvas until the screen woke up. > > > 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
