So... in describing this feature: Is it really the visibility of the page that is being queried - or the some kind of state of a window? Maybe it's a silly bit of semantics, but it seems clearer to me that most of the things discussed here are about a whole window/tab being "minimized" (either to a taskbar or tab or something). If I have one app open and it is covering a browser window - the browser window is not visible (it's lower in the stacking order). Likewise, a page is generally "partially" visible (scrollbars) so that seems more confusing than it needs to be too.
On Tue, Oct 20, 2009 at 7:41 PM, Maciej Stachowiak <m...@apple.com> wrote: > > On Oct 20, 2009, at 7:13 PM, Ennals, Robert wrote: > > One thing I like about the "requestAnimationFrame" approach is that it makes > it easy to do the right thing. If the simplest approach burns CPU cycles, > and programmers have to think a bit harder to avoid doing this, then I > suspect the likely outcome would be that many programmers will take the > shortest path, and not check whether their page is visible. > > It's nice if you are able to re-engineer your animations enough to make use > of it. The other approaches discussed seem easier to bolt on to existing > code. > Note: if you really want to optimize CPU use, then the best thing IMO is to > use CSS Transitions or CSS Animations, that way the browser is fully in > control of the frame rate and in many cases can do most of the work on the > GPU, with no need to execute any script as the animation goes. I think this > has the potential to be more CPU-friendly than the requestAnimationFrame > approach, though obviously it's not applicable in some cases (e.g. canvas > drawing). > > I'd even be tempted to risk breaking existing applications a little bit and > make the *default* behavior for HTML5 pages be that "time stops" when a page > is not visible. If a programmer has a good reason to run javascript on an > invisible page then they should have to pass an option to make it clear that > they know what they are doing. > > One challenge with this approach is that there's no good way at present to > make time stop for a plugin. I suspect more generally that this approach > would cause compatibility bugs. > Regards, > Maciej >
