Re: [whatwg] window.setInterval if visible.
On Thu, Oct 15, 2009 at 10:53 PM, Markus Ernst derer...@gmx.ch wrote: From a performance point of view it might even be worth thinking about the contrary: Allow UAs to stop the execution of scripts on non-visible windows or elements by default, and provide a method to explicitly specify if the execution of a script must not be stopped. fwiw, the N900 browser (microb) does this by default. it breaks google talk in gmail among other things. (You can turn this option off through the browser menus, you don't need to use about:config.) in many ways it's bad, especially since once broken, pages can't really be fixed, and users don't really understand that we broke it because they let us. being able to send a Hibernate and Resume event pair to web apps could be neat, but we don't have the resources to see if we could convince pages to respond to them. If you provide methods to check the visibility of a window or element, you leave it up to the author to use them or not. I think performance issues should rather be up to the UA. We're trying, but, well, it's too early to see what people will say about our efforts. (fwiw, I work on the team which did this, but I'm entirely opposed to it, because explaining it to authors and users is impossible/impractical).
Re: [whatwg] window.setInterval if visible.
On Fri, Oct 30, 2009 at 12:23 AM, timeless timel...@gmail.com wrote: On Thu, Oct 15, 2009 at 10:53 PM, Markus Ernst derer...@gmx.ch wrote: From a performance point of view it might even be worth thinking about the contrary: Allow UAs to stop the execution of scripts on non-visible windows or elements by default, and provide a method to explicitly specify if the execution of a script must not be stopped. fwiw, the N900 browser (microb) does this by default. it breaks google talk in gmail among other things. (You can turn this option off through the browser menus, you don't need to use about:config.) in many ways it's bad, especially since once broken, pages can't really be fixed, and users don't really understand that we broke it because they let us. being able to send a Hibernate and Resume event pair to web apps could be neat, but we don't have the resources to see if we could convince pages to respond to them. Why don't you just treat this like bfcache and fire pagehide and pageshow events? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] window.setInterval if visible.
On Thu, 15 Oct 2009, Boris Zbarsky wrote: On 10/15/09 3:35 PM, Gregg Tavares wrote: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. You might be interested in http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/527d0cedb9b0df7f/57625c94cdf493bf for some more discussion about approaches to this problem. In particular, that proposal tries to address overeager animations in visible windows as well. Note, by the way, that testing whether a window is visible is not cheap; testing whether an element is visible is even less cheap On Thu, 15 Oct 2009, Jeremy Orlow wrote: I'd imagine that UAs could use an overly conservative metric of when things are visible to make things cheaper if/when this is a concern. All that really matters is that the UA never say it isn't visible when any part of the window is visible. I agree that some mechanism to know when things aren't visible would be very useful. On Thu, 15 Oct 2009, Boris Zbarsky wrote: It's a concern any time someone's checking it every 10ms interval invocation. For example, I'm right now looking at a browser window where the check would probably take longer than that (ping time from the X client to the X server is 50ms in this case). What are the use cases? Are they addressed by roc's proposal? If not, is an explicit script-triggered visibility check the only way to address them? On Thu, 15 Oct 2009, João Eiras wrote: You're trying to solve a real problem with a very specific API. You might use setInterval, but someone else might use a worker or setTimeout. The best way would be an attribute on the window, like window.isVisible returning either true of false which would return true if the document is partially or totally visible. This way, all other possible use cases to prevent animations or other complex and heavy dom/layout operations could be postponed just by checking that value. I personally think it's a good idea to have that info available. On Thu, 15 Oct 2009, Markus Ernst wrote: From a performance point of view it might even be worth thinking about the contrary: Allow UAs to stop the execution of scripts on non-visible windows or elements by default, and provide a method to explicitly specify if the execution of a script must not be stopped. If you provide methods to check the visibility of a window or element, you leave it up to the author to use them or not. I think performance issues should rather be up to the UA. On Fri, 16 Oct 2009, Gregg Tavares wrote: I agree that would be ideal. Unfortunately, current webpages already expect setInternval to function even when they are not visible. web based chat and mail clients come to mind as examples. So, unfortunately, it doesn't seem like a problem a UA can solve on it's own. On the otherhand, if the solution is as simple as add a flag to setInterval then it's at least a very simple change for those apps that want to not hog the CPU when not visible. I haven't added this feature to HTML5, as it seems more of a presentational thing and would be best addressed in a spec like CSSOM. I would recommend taking this up in the webapps group. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] window.setInterval if visible.
On Thu, Oct 15, 2009 at 1:53 PM, Markus Ernst derer...@gmx.ch wrote: Gregg Tavares schrieb: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. Here's the issue that seems like it needs to be solved. Currently, AFAIK, the only way to do animation in HTML5 + JavaScript is using setInterval. That's great but it has the problem that even when the window is minimized or the page is not the front tab, JavaScript has no way to know to stop animating. So, for a CPU heavy animation using canvas 2d or canvas 3d, even a hidden tab uses lots of CPU. Of course the browser does not copy the bits from the canvas to the window but JavaScript is still drawing hundreds of thousands of pixels to the canvas's internal image buffer through canvas commands. [...] There are probably other possible solutions to this problem but it seems like the easiest would be either *) adding an option to window.setInterval or only callback if the window is visible *) adding window.setIntervalIfVisible (same as the previous option really) A possibly better solution would be *) element.setIntervalIfVisible Which would only call the callback if that particular element is visible. From a performance point of view it might even be worth thinking about the contrary: Allow UAs to stop the execution of scripts on non-visible windows or elements by default, and provide a method to explicitly specify if the execution of a script must not be stopped. If you provide methods to check the visibility of a window or element, you leave it up to the author to use them or not. I think performance issues should rather be up to the UA. I agree that would be ideal. Unfortunately, current webpages already expect setInternval to function even when they are not visible. web based chat and mail clients come to mind as examples. So, unfortunately, it doesn't seem like a problem a UA can solve on it's own. On the otherhand, if the solution is as simple as add a flag to setInterval then it's at least a very simple change for those apps that want to not hog the CPU when not visible.
[whatwg] window.setInterval if visible.
I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. Here's the issue that seems like it needs to be solved. Currently, AFAIK, the only way to do animation in HTML5 + JavaScript is using setInterval. That's great but it has the problem that even when the window is minimized or the page is not the front tab, JavaScript has no way to know to stop animating. So, for a CPU heavy animation using canvas 2d or canvas 3d, even a hidden tab uses lots of CPU. Of course the browser does not copy the bits from the canvas to the window but JavaScript is still drawing hundreds of thousands of pixels to the canvas's internal image buffer through canvas commands. To see an example run this sample in any browser http://mrdoob.com/projects/chromeexperiments/depth_of_field/ Minimize the window or switch to another tab and notice that it's still taking up a bunch of CPU time. Conversely, look at this flash page. http://www.alissadean.com/ While it might look simple there is actually a lot of CPU based pixel work required to composite the buttons with alpha over the scrolling clouds with alpha over the background. Minimize that window or switch to another tab and unlike HTML5 + JavaScript, flash has no problem knowning that it no longer needs to render. There are probably other possible solutions to this problem but it seems like the easiest would be either *) adding an option to window.setInterval or only callback if the window is visible *) adding window.setIntervalIfVisible (same as the previous option really) A possibly better solution would be *) element.setIntervalIfVisible Which would only call the callback if that particular element is visible. It seems like this will be come an issue as more and more HMTL5 pages start using canvas to do stuff they would have been doing in flash like ads or games. Without a solution those ads and games will continue to eat CPU even when not visible which will make the user experience very poor. Am I making an sense? -gregg
Re: [whatwg] window.setInterval if visible.
On 10/15/09 3:35 PM, Gregg Tavares wrote: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. You might be interested in http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/527d0cedb9b0df7f/57625c94cdf493bf for some more discussion about approaches to this problem. In particular, that proposal tries to address overeager animations in visible windows as well. Note, by the way, that testing whether a window is visible is not cheap; testing whether an element is visible is even less cheap -Boris
Re: [whatwg] window.setInterval if visible.
On Thu, 15 Oct 2009 21:35:03 +0200, Gregg Tavares g...@google.com wrote: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. You're trying to solve a real problem with a very specific API. You might use setInterval, but someone else might use a worker or setTimeout. The best way would be an attribute on the window, like window.isVisible returning either true of false which would return true if the document is partially or totally visible. This way, all other possible use cases to prevent animations or other complex and heavy dom/layout operations could be postponed just by checking that value. I personally think it's a good idea to have that info available.
Re: [whatwg] window.setInterval if visible.
On Thu, Oct 15, 2009 at 12:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/15/09 3:35 PM, Gregg Tavares wrote: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. You might be interested in http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/527d0cedb9b0df7f/57625c94cdf493bffor some more discussion about approaches to this problem. In particular, that proposal tries to address overeager animations in visible windows as well. Note, by the way, that testing whether a window is visible is not cheap; testing whether an element is visible is even less cheap I'd imagine that UAs could use an overly conservative metric of when things are visible to make things cheaper if/when this is a concern. All that really matters is that the UA never say it isn't visible when any part of the window is visible. I agree that some mechanism to know when things aren't visible would be very useful.
Re: [whatwg] window.setInterval if visible.
Gregg Tavares schrieb: I was wondering if there as been a proposal for either an optional argument to setInterval that makes it only callback if the window is visible OR maybe a window.setRenderInterval. Here's the issue that seems like it needs to be solved. Currently, AFAIK, the only way to do animation in HTML5 + JavaScript is using setInterval. That's great but it has the problem that even when the window is minimized or the page is not the front tab, JavaScript has no way to know to stop animating. So, for a CPU heavy animation using canvas 2d or canvas 3d, even a hidden tab uses lots of CPU. Of course the browser does not copy the bits from the canvas to the window but JavaScript is still drawing hundreds of thousands of pixels to the canvas's internal image buffer through canvas commands. [...] There are probably other possible solutions to this problem but it seems like the easiest would be either *) adding an option to window.setInterval or only callback if the window is visible *) adding window.setIntervalIfVisible (same as the previous option really) A possibly better solution would be *) element.setIntervalIfVisible Which would only call the callback if that particular element is visible. From a performance point of view it might even be worth thinking about the contrary: Allow UAs to stop the execution of scripts on non-visible windows or elements by default, and provide a method to explicitly specify if the execution of a script must not be stopped. If you provide methods to check the visibility of a window or element, you leave it up to the author to use them or not. I think performance issues should rather be up to the UA.
Re: [whatwg] window.setInterval if visible.
On 10/15/09 4:14 PM, Jeremy Orlow wrote: I'd imagine that UAs could use an overly conservative metric of when things are visible to make things cheaper if/when this is a concern. It's a concern any time someone's checking it every 10ms interval invocation. For example, I'm right now looking at a browser window where the check would probably take longer than that (ping time from the X client to the X server is 50ms in this case). I agree that some mechanism to know when things aren't visible would be very useful. What are the use cases? Are they addressed by roc's proposal? If not, is an explicit script-triggered visibility check the only way to address them? -Boris
