How to detect if browser in background - WebGL 100% CPU

[Alecazam]

I realize requestAnimFrame will throttle the app when a tab is switched, but how do you throttle WebGL apps when the browser is in the background but the tab isn't or when the browser is minimized?  I'm routinely seeing my battery die because I left a WebGL app running in the browser but it's covered over by windows.   Windows has a DX test for whether a window is obscured, but I'm looking for simpler data that the browser isn't the foreground process.

[Tom Payne]

The Page Visibility API might be what you need:

  https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API

On 22 March 2014 16:41, Alecazam <al...@figma.com> wrote:

I realize requestAnimFrame will throttle the app when a tab is switched, but how do you throttle WebGL apps when the browser is in the background but the tab isn't or when the browser is minimized?  I'm routinely seeing my battery die because I left a WebGL app running in the browser but it's covered over by windows.   Windows has a DX test for whether a window is obscured, but I'm looking for simpler data that the browser isn't the foreground process.

--
You received this message because you are subscribed to the Google Groups "WebGL Dev List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webgl-dev-lis...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Camptocamp SA
Tom PAYNE
PSE A
CH-1015 Lausanne

+41 21 619 10 13 (direct)
+41 21 619 10 10 (centrale)
+41 21 619 10 00 (fax)

[Ben Adams]

You can use the PageVisibility Api

http://www.w3.org/TR/page-visibility/

http://www.html5rocks.com/en/tutorials/pagevisibility/intro/

https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API

Ben Adams

@ben_a_adams

On 22 March 2014 15:41, Alecazam <al...@figma.com> wrote:

I realize requestAnimFrame will throttle the app when a tab is switched, but how do you throttle WebGL apps when the browser is in the background but the tab isn't or when the browser is minimized?  I'm routinely seeing my battery die because I left a WebGL app running in the browser but it's covered over by windows.   Windows has a DX test for whether a window is obscured, but I'm looking for simpler data that the browser isn't the foreground process.

--

[Alecazam]

I should add that it feels like requestAnimFrame could offer the app an opportunity to throttle down it's update rate if it detected the browser was put in the background or minimized).

[Alecazam]

My understanding is those only work if the tab is switched out for another.  If the tab is visible but hidden by other windows, then WebGL continues to run at full or at least high enough frame rate to burn up my battery/cpu.  I also minimized the following, and didn't see the audio stop playing in Chrome, but that could be by design.

http://www.samdutton.com/pageVisibility/

[Kenneth Russell]

You're correct that there's no browser API that specifically tells
when the window is completely obscured by others. This can plausibly
be handled by the Page Visibility API, given improvements to the
implementations of that API. Mac OS X 10.9 adds a new occlusion API
which Chrome could use to send visibilitychanged=hidden events to
occluded windows.

I can confirm that Chrome doesn't send visibilitychanged events upon
minimize/maximize, only upon the tab going to the background or
foreground. Firefox does though. A bug was filed about this a while
ago: crbug.com/246844 . Please star it to attract attention to fixing
it.

Depending on how your app works, you should probably determine whether
to stop animating the view based on app-specific heuristics: for
example, if the user goes idle for some period of time, stop
animation. Or use the onblur event to watch for focus lost events and
stop animation.

-Ken

[Alecazam]

Since these APIs are still a bit exotic and unique to the newer OS vesions, I was hoping there was a simpler solution of just having the browser communicate the app was a background process or not through the visibility API.  Obviously, knowing that the browser was minimized would help too, but that just feels like the extreme form of being in the background.  On desktop systems, the app can keep processing 2D or 3D renders or throttle itself, though on mobile when in the background GL usage is still not possible.    

[Mark Callow]

On 2014/03/23 0:54, Alecazam wrote:

I should add that it feels like requestAnimFrame could offer the app an opportunity to throttle down it's update rate if it detected the browser was put in the background or minimized).

Yes. I was about to suggest something similar.

The browser simply not calling the rAF callback when the tab is not visible or the browser is backgrounded would probably work for the majority of applications. We could add an optional dontCallWhenHidden flag to rAF for applications to request this.

Applications doing simulations could either always be called by rAF or could run their simulations from an interval timer and set the new flag.

Applications composing an image in the canvas over multiple frames would want to be called regardless of hidden status.

For applications doing off-screen drawing it is not clear to me that rAF is the right thing to use in the first place.

Regards

    -Mark

--

注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.

[Kenneth Russell]

On Wed, Mar 26, 2014 at 7:16 PM, Mark Callow <callo...@artspark.co.jp> wrote:
> On 2014/03/23 0:54, Alecazam wrote:
>
> I should add that it feels like requestAnimFrame could offer the app an
> opportunity to throttle down it's update rate if it detected the browser was
> put in the background or minimized).
>
> Yes. I was about to suggest something similar.
>
> The browser simply not calling the rAF callback when the tab is not visible
> or the browser is backgrounded would probably work for the majority of
> applications. We could add an optional dontCallWhenHidden flag to rAF for
> applications to request this.

Chrome and, I believe, other browsers already don't call rAF on
backgrounded tabs. This mechanism is tied into the implementation of
the Page Visibility API, so if that implementation were improved to
better handle minimized or occluded windows, it would take effect
there too.

-Ken

> Applications doing simulations could either always be called by rAF or could
> run their simulations from an interval timer and set the new flag.
>
> Applications composing an image in the canvas over multiple frames would
> want to be called regardless of hidden status.
>
> For applications doing off-screen drawing it is not clear to me that rAF is
> the right thing to use in the first place.
>
> Regards
>
> -Mark
>
> --
> 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、
> 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.
>
> NOTE: This electronic mail message may contain confidential and privileged
> information from HI Corporation. If you are not the intended recipient, any
> disclosure, photocopying, distribution or use of the contents of the
> received information is prohibited. If you have received this e-mail in
> error, please notify the sender immediately and permanently delete this
> message and all related copies.
>

[Alecazam]

> Chrome and, I believe, other browsers already don't call rAF on backgrounded tabs.

What I was suggesting isn't background/foreground tabs.  I want to suppress the app (or app window) when it is in the background but displaying WebGL in a foreground tab.   That's what is not currently un-throttled.   The visiblity api should probably not do any suppression of RAF, but it should supply as much data as it can for the RAF-using app to respond appropriately and throttle itself appropriately.