Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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=123612991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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. 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. 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=123612991iu=/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=123612991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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. 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. 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=123612991iu=/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=123612991iu=/4140/ostg.clktrk ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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=123612991iu=/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
Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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=123612991iu=/4140/ostg.clktrk
Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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. 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. :) 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
Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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. 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
Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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
Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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
Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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
Re: [E-devel] [EGIT] [core/enlightenment] master 01/02: feature: main idlers now freeze during screensaver to conserve power
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
