[whatwg] window.setInterval if visible.

Ian Hickson ian at hixie.ch
Sat Oct 17 20:23:20 PDT 2009


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.   `._.-(,_..'--(,_..'`-.;.'


More information about the whatwg mailing list