I'm concerned if this is a good idea. Users generally expect that windows that are not minimized work normally and throttling stuff may have unintended side effects. Also it requires plumbing occlusion into a new and different space (and probably computing it in another place). We could experiment but we should look at what are the side effects.

This is a nice to have, and it may not be strictly required for Mus+Ash but it's useful to consider.

Again, we don't know if we need this, at least in the short term, but this is an optimization that I'd like to keep thinking of just in case we might need it in the future. I think it might makes sense to do this in the display compositor for occluded things in general. Perhaps this could feed off surface draw occlusion that we build? 

Maybe surfaces that are not drawn (aren't included in SurfaceAggregator::Aggregate) get throttled?

Unrelated but I just remembered that now that surface synchronization is almost ready, we have the option to do some clever raster occlusion plumbing by allocating new surface IDs in the parent as the occluded area changes (perhaps we can be conservative here) and then use surface synchronization to ensure we don't checkerboard windows (most of the time). This might be a bad idea because we might jank as we move windows around. I'm writing down the idea here anyway to think about later.

Related (for mac) https://bugs.chromium.org/p/chromium/issues/detail?id=699559#c7

#5: We can probably do a pretty good job of keeping window checkerboarding to a minimum on Chrome OS with surface synchronization because the compositor owns the whole screen. On other platforms, this is more of a challenge because we might need to synchronously produce content when the window is exposed or we checkerboard.

With that said, throttling BeginFrames (which is what this bug is about :P) ought to be doable on other platforms. The worst we'll experience on window exposure is a bit of a stutter. 

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

To Fady to triage. Is conceivably obsolete in a Mus+ash context.

This is still a nice to have. 

Passing along to sky@ for triage. This is a nice-to-have for OOP-Ash. Might need it for performance reasons.

Fady, could you provide some more details about what this would entail and what the benefits would be? Pass it back to me once you do that.

I know there's some work done on window occlusion lately so maybe this is actually already fixed (not sure who's been working on it). 

At the time this bug was filed, occluded windows with animations or videos would stick tick at 60fps even though the user didn't see any changes on screen. This wastes a lot of cycles and could cause Chrome OS as a whole to feel sluggish. This was a possible mitigation we listed. This may not be relevant or important anymore but something to consider. 

Thanks Fady. I'm going to mark available in case anyone wants to take it over.