Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome will aggressively throttle background tabs

blog.strml.net

Post reply on HN
Print view View original

111–120 of 403 posts

Re: Chrome will aggressively throttle background tabs

#111

Post by xigency »

dumbmatter wrote: post #64
ben_jones wrote: post #29

Earlier quoted context omitted.

Could you create a tabbed interface that is just a dumb view of a server state communicated over websockets? Then the user could just open the page in n windows (each on its own tab) and have the same state represented in each?

Problem is, there is no server. All client side. So the tab on which you click "run simulation" is effectively the "server", except it stops running when the user switches tabs.

The fact that you don't have a backend is the limiting factor here.

Re: Chrome will aggressively throttle background tabs

#112

Post by onion2k »

dumbmatter wrote: post #4

What are we supposed to do about stuff this? Like I wrote a video game https://play.basketball-gm.com/ that lets you open multiple tabs for viewing multiple screens even while simulation is occurring in another tab. But Chrome recently stopped running the simulation if it's in a background tab. Putting my simulation code in a Shared Worker would be nice, except Safari and IE will never support it and it seems likely…

As a developer you need to decide whether or not to support a browser, and if that browser doesn't provide the APIs you need then you should drop support for that feature in that browser. In this case, if Chrome is making a change that you can't or won't change your game for then the solution is to detect Chrome and display a "This game only works in a single tab in Chrome. Try Firefox!" message if a user opens it in a second tab.

Re: Chrome will aggressively throttle background tabs

#113

Post by Ambroos »

croddin wrote: post #72
Spoom wrote: post #56

Earlier quoted context omitted.

I don't believe it will. From https://groups.google.com/a/chromium.org/forum/#!topic/blink... : Background tabs usually do not have a visible impact for user (tabs with audio are always considered foregrounded).

Is that a workaround/loophole then? A tab can play silent or very quiet audio and then run unthrottled?

Chrome's audio detection is quite smart if I'm not mistaken. A tiny amount of sound is usually seen as 'silent' too, since it'd be practically inaudible.

Re: Chrome will aggressively throttle background tabs

#114

Post by CamelCaseName »

croddin wrote: post #72
Spoom wrote: post #56

Earlier quoted context omitted.

I don't believe it will. From https://groups.google.com/a/chromium.org/forum/#!topic/blink... : Background tabs usually do not have a visible impact for user (tabs with audio are always considered foregrounded).

Is that a workaround/loophole then? A tab can play silent or very quiet audio and then run unthrottled?

I believe users would quickly find that suspicious as Chrome shows you which tabs are playing sound.

Re: Chrome will aggressively throttle background tabs

#115

Post by tantalor »

STRML wrote: post #105
tantalor wrote: post #94

Earlier quoted context omitted.

Explain how that is different?

It's different because it can't just slow down a running task. Say you use up 150ms of CPU time. Chrome isn't going to let another timer fire for 15s. Then, you're late on a whole bunch of work that needs to get done, so the next timer takes 500ms. Chrome then throttles the next timer by 50s. And so on and so forth...

But if your script had 1% of CPU, that 150ms workload would take 15s to complete. Then the next workload would be late in the same way and take 50s to complete.

How is this different?

Re: Chrome will aggressively throttle background tabs

#116

Post by STRML »

STRML wrote: post #101
joemccall86 wrote: post #53

Earlier quoted context omitted.

Excellent work! Kind of funny the article mentions > This will break the web. But apparently blogger requires javascript just to render static content.

Oh, it's awful, I agree. This is the nicest layout but the JS is terrible. I've reverted to a plain-HTML layout.

To whoever downvoted this: I am the author of the post above, and in response I've removed the JS-centric layout.

Re: Chrome will aggressively throttle background tabs

#117

Post by STRML »

tantalor wrote: post #115
STRML wrote: post #105

Earlier quoted context omitted.

It's different because it can't just slow down a running task. Say you use up 150ms of CPU time. Chrome isn't going to let another timer fire for 15s. Then, you're late on a whole bunch of work that needs to get done, so the next timer takes 500ms. Chrome then throttles the next timer by 50s. And so on and so forth...

But if your script had 1% of CPU, that 150ms workload would take 15s to complete. Then the next workload would be late in the same way and take 50s to complete. How is this different?

It depends on what you're doing. If you split up tasks and interleaves them (such as: process a few items, stop, set another timer, process a few more), actual CPU% throttling would be better. It would be easier to have certain timers take priority, such as heartbeat responses or notifications.

Re: Chrome will aggressively throttle background tabs

#118

Post by philsnow »

koheripbal wrote: post #91
jklinger410 wrote: post #78

Earlier quoted context omitted.

Pinned tabs would be an easy solution for this. "Don't throttle pinned tabs"

A common use-case is tabs that are streaming music. I'm not sure if most users are even aware of pinned tabs.

didn't they remove pinned tabs a while back, and then re-add them?

Re: Chrome will aggressively throttle background tabs

#119

Post by tyingq »

koheripbal wrote: post #91
jklinger410 wrote: post #78

Earlier quoted context omitted.

Pinned tabs would be an easy solution for this. "Don't throttle pinned tabs"

A common use-case is tabs that are streaming music. I'm not sure if most users are even aware of pinned tabs.

They are making an exception for tabs that are playing audio.

You can see the discussion back and forth, here: https://groups.google.com/a/chromium.org/forum/#!topic/blink...

I can see where that will end up though. Everyone who's app was broken by this change will start playing zero volume audio, then the exception will be yanked back.

With the web poised to be the new platform for applications, there really needs to be some more thought put into how to accomplish that goal. The chrome devs already sunset some solutions in that space, like the HTML5 app cache. Now this. Nobody likes a constantly moving target.

Re: Chrome will aggressively throttle background tabs

#120

Post by baby »

blauditore wrote: post #110
mcescalante wrote: post #8

It's awesome to see Chrome trying to improve performance for people with many tabs open, which is many of us. I use a LOT of tabs, and the best plugin has been The Great Suspender. Highly recommend it for anyone who wants memory & CPU back and keeps many tabs/windows open at once: https://chrome.google.com/webstore/detail/the-great-suspende...

I meet many tab hoarders (always open a new one, never close any, ending up with hundrets), but just can't wrap my head around it! I hate having more than 6-7 simultaneously open because it gets increasingly harder to keep an overview of what you're doing. The same applies for IDE tabs or windows. Too much of them and finding the right one becomes increasingly hard, and losing the thread more likely.

Not if you use Tree Style Tabs. I've been using it for years and I have no idea how other people can efficiently browse the web without it.
Post reply on HN