+erikchen

I've managed to reproduce this locally. This is definitely an issue with fullscreen low power. We make the transition without a flicker about 95% of the time. But, we make the transition every time subtitles appear or disappear, so 95% success means "fails every few minutes".

The correct fix for this is to pop out a new window for fullscreen video, so that we don't have to do the flipping hack.

Also of note is that only hardware-accelerated video benefits from fullscreen low power mode (vp9's GPU power usage was already near that mode, and doesn't change). But we use AVFoundation in both cases, so in the short term we can disable AVFoundation for non-h264 to minimize the impact.

I've played with this for a little while, and I have some observations.

I've seen flashes both entering and leaving FSLP.

For entering, if we set NSFullScreenWindowMask when the fullscreen transition ends, but before we show the window, then the flash seems to go away.

For leaving, if we keep the last FSLP frame alive for a few frames before flushing it out, the issue appears to go away. This was a TODO that I added because I thought it might be necessary, but it never ended up causing issues (https://cs.chromium.org/chromium/src/ui/accelerated_widget_mac/ca_layer_tree_coordinator.mm?rcl=0&l=99).

I need to verify that these changes don't actually break the power savings.

And, fullscreen low power mode is broken on 10.12.1.

It's probably the "fix" that we got for  issue 652409  in Sierra 10.12.1.

Is there a test that would catch if low power mode breaks? I believe we still don't have 10.12 bots but wondering if we did would we have caught it? Do bots even get regularly updated to incremental macOS releases?

We have a FSLP test, but we don't have any 10.12 bots anywhere.
https://bugs.chromium.org/p/chromium/issues/detail?id=651475

I imagine the test would have caught the issue. There is no formalized process for upgrading bots per macOS release.

Re: updates, I was just thinking that even if we had 10.12 bots, if they were 10.12.0, say, and we don't update bots regularly, and FSLP was broken by 10.12.1, we wouldn't have caught the regression even though we have a test.

I should add that it's still my speculation that FSLP was broken by 10.12.0 -> 10.12.1

I'm "like pretty sure" that I verified that we hit FSLP at some point on Sierra, but I never documented it.

I think that the core issue here is that we used an unsupported API (remote layers), Apple put in workarounds because we're on their "do not break" list, but they only tested the workarounds superficially (we're not *their* app, afterall), and so we've been exploring all of the broken corner cases in Sierra for the last few months.

I jumped the gun about FSLP being broken. My test machine was in a bad state, and seems to have resolved itself upon reboot.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d8ca506c965aa6331149055e421c9d2e9c2b14ab

commit d8ca506c965aa6331149055e421c9d2e9c2b14ab
Author: ccameron <ccameron@chromium.org>
Date: Thu Nov 03 02:15:07 2016

Mac: Fix flickering while entering/leaving fullscreen low power video

Change the low power transition to be 3-state. The states are
- not in FSLP mode, FSLP window is hidden
- warming up FSLP mode, FSLP window is visible and in the fullscreen
  state, but is behind the main window
- in FSLP mode. the FLSP window is in front of the main window

From my experiments, adding up this "warming up" state, makes it so
that the flahses when entering FSLP mode go away.

When exiting FSLP mode, it used to be that we would call
-[AVSampleBufferDisplayLayer flushAndRemoveImage] immediately, since
it never caused any issues. I was able to see some black flashes on
Sierra. If I change it so that we wait for 15 frames to do this, then
the flashes go away.

BUG= 661691 

Review-Url: https://codereview.chromium.org/2468063004
Cr-Commit-Position: refs/heads/master@{#429515}

[modify] https://crrev.com/d8ca506c965aa6331149055e421c9d2e9c2b14ab/chrome/browser/ui/cocoa/fullscreen_low_power_coordinator.h
[modify] https://crrev.com/d8ca506c965aa6331149055e421c9d2e9c2b14ab/chrome/browser/ui/cocoa/fullscreen_low_power_coordinator.mm
[modify] https://crrev.com/d8ca506c965aa6331149055e421c9d2e9c2b14ab/chrome/browser/ui/cocoa/fullscreen_low_power_coordinator_unittest.mm
[modify] https://crrev.com/d8ca506c965aa6331149055e421c9d2e9c2b14ab/ui/accelerated_widget_mac/ca_layer_tree_coordinator.h
[modify] https://crrev.com/d8ca506c965aa6331149055e421c9d2e9c2b14ab/ui/accelerated_widget_mac/ca_layer_tree_coordinator.mm

border-480 shows the root cause of the issue. When there are borders we're not in low power mode, when the borders disappear, we're in low power mode. It's at the transition between the two modes that we get noticeable flashes.

That said, there is another problem, namely, that we will create-and-then-destroy the AVSampleBufferDisplayLayer at some frames. This is because we're reconstructing the layer tree from the draw quads, so we're doing a sort of "best guess" matchup of layers, and sometimes we miss that. When we miss this, it's pretty obvious with borders attached.

It may be worth opening a second bug on aggressively re-using AVSampleBufferDisplayLayers, even when they don't match up in the layer tree.

flash-480 shows a repro of the original issue. The flash is noticeable a split second after subtitles have been gone for a while. There is also a jank when the subtitles re-appear.

wth-fix-480 shows the behavior on Canary with the fix.

TIL that renaming files to .mp4 will display them inline! Attaching renamed versions.

Deleted: borders-480.mp4 4.3 MB

	borders-480.mp4 4.3 MB View Download

Deleted: flash-480.mp4 2.4 MB

	flash-480.mp4 2.4 MB View Download

Deleted: with-fix-480.mp4 2.2 MB

	with-fix-480.mp4 2.2 MB View Download

Requesting M55 merge.

Your change meets the bar and is auto-approved for M55 (branch: 2883)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1a355d41f458d67709d6c72144cec4560c0af24e

commit 1a355d41f458d67709d6c72144cec4560c0af24e
Author: Christopher Cameron <ccameron@chromium.org>
Date: Fri Nov 04 22:01:58 2016

Mac: Fix flickering while entering/leaving fullscreen low power video

Change the low power transition to be 3-state. The states are
- not in FSLP mode, FSLP window is hidden
- warming up FSLP mode, FSLP window is visible and in the fullscreen
  state, but is behind the main window
- in FSLP mode. the FLSP window is in front of the main window

From my experiments, adding up this "warming up" state, makes it so
that the flahses when entering FSLP mode go away.

When exiting FSLP mode, it used to be that we would call
-[AVSampleBufferDisplayLayer flushAndRemoveImage] immediately, since
it never caused any issues. I was able to see some black flashes on
Sierra. If I change it so that we wait for 15 frames to do this, then
the flashes go away.

BUG= 661691 

Review-Url: https://codereview.chromium.org/2468063004
Cr-Commit-Position: refs/heads/master@{#429515}
(cherry picked from commit d8ca506c965aa6331149055e421c9d2e9c2b14ab)

Review URL: https://codereview.chromium.org/2479723003 .

Cr-Commit-Position: refs/branch-heads/2883@{#464}
Cr-Branched-From: 614d31daee2f61b0180df403a8ad43f20b9f6dd7-refs/heads/master@{#423768}

[modify] https://crrev.com/1a355d41f458d67709d6c72144cec4560c0af24e/chrome/browser/ui/cocoa/fullscreen_low_power_coordinator.h
[modify] https://crrev.com/1a355d41f458d67709d6c72144cec4560c0af24e/chrome/browser/ui/cocoa/fullscreen_low_power_coordinator.mm
[modify] https://crrev.com/1a355d41f458d67709d6c72144cec4560c0af24e/chrome/browser/ui/cocoa/fullscreen_low_power_coordinator_unittest.mm
[modify] https://crrev.com/1a355d41f458d67709d6c72144cec4560c0af24e/ui/accelerated_widget_mac/ca_layer_tree_coordinator.h
[modify] https://crrev.com/1a355d41f458d67709d6c72144cec4560c0af24e/ui/accelerated_widget_mac/ca_layer_tree_coordinator.mm

Tested the issue on MacBook Pro (Retina, Mid 2012) using chrome version 55.0.2883.44 with the URL https://www.netflix.com/in/

1. Played the movie with subtitles ON
2. Entered into full screen mode.
Observed the screen flashes every few minutes.

Please find the attached screen shot for the same and observe the screen flash at 0.23 sec

Deleted: Issue-661691.mp4 2.8 MB

	Issue-661691.mp4 2.8 MB View Download

Interesting. So, I managed to make that go away on my machine, but I'm not sure what the story is with this bug -- that build is indeed after my fix was merged.

Some flash is OK for low power mode (like -- I made stand-alone applications that had some flash because Apple is changing the display mode), but it's not OK if the flash occurs whenever we add/remove subtitles.

Not sure what to do about this.

So, yes, that flash is at least part of the issue  -- I'm curious if it happens frequently when watching movies with subtitles on Netflix.

We're just going to have to do testing on more hardware/software configurations...

Based on offline chat with ccameron@ I am tagging the bug as M-55 stable blocker.

**** Bulk edit -  please ignore if not applicable ****


A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

Also due to Thanksgiving holidays in US, please make sure fix is ready and merged to M55 latest by 5:00 PM PT Friday, 11/18/16 (sooner the better).

 Issue 663205  has been merged into this issue.

WRT RBS: I'd like to check with Apple if the issue is fixed by the changes that have been made.

@ ccameron: Gentle ping, any update on this as per the above comment.

Thanks.!

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch latest by November 25th, 5:00 PM PST in order to make into the desktop Stable final build cut. Thank you!

Let's move this to M56 -- we've reached out to Apple to verify the fix, but haven't heard yet.

 Issue 652409  has been merged into this issue.

Reports of the crashy version of this ( issue 652409 ) in the wild:
https://www.reddit.com/r/chrome/comments/5549mo/chrome_problems/
https://discussions.apple.com/thread/7687363
https://productforums.google.com/forum/#!topic/chrome/O_IW8MNN11Y
https://productforums.google.com/forum/#!topic/chrome/1spDA0Km4Iw
https://productforums.google.com/forum/#!topic/chrome/kWYdef86ZJU

 Issue 644132  has been merged into this issue.

Can we have the latest update on this issue?

verfied this issue on MacBook Pro (Retina, Mid 2012) using chrome version 57.0.2950.0 with the URL https://www.netflix.com/in/

No flickering is observed while playing videos with subtitles ON.
Attaching the screencast for your reference.

ccameron@ Could you confirm whether this issue is fixed or not ?

Deleted: Issue 661691-M57.mp4 14.0 MB

	Issue 661691-M57.mp4 14.0 MB View Download

Continuing to ping Apple offline.

Tested the issue on Mac 10.12.1 using chrome version 57.0.2970.0.Not observed any flickering while playing videos on https://www.netflix.com/in/.

ccameron@ Can we have any update on this stable blocker issue?

Thanks,

Same as #34, still waiting to hear back from Apple.

Until they can be bothered to check if it is fixed for them, it shouldn't block anything.

Looks like APPLE bug,removing RBS for now.

Apple has verified and closed the bug on their end. Closing ours too.