On High Sierra, detached mode (FSLP) may start wildly flickering |
|||||||
Issue descriptionChrome Version: 65.0.3286.0 OS: macOS 10.13.2 — **10.13+ only!** What steps will reproduce the problem? (1) Open the attached thinvideo.mp4 or thinvideo.webm (they're the same). (2) Make the video fullscreen. (3) Hit play. What is the expected result? The controls hide after a few seconds. What happens instead? The controls hide after a few seconds, and the video's horizontal alignment starts changing wildly. You can set the video to loop if you want it to keep happening. (I think this is at least partly a macOS bug, will post a comment shortly with more info.)
,
Dec 6 2017
CL with more detail about what triggers this: https://chromium-review.googlesource.com/c/chromium/src/+/812114
,
Dec 11 2017
Hey Sidney! thanks for working on this fix. Just a heads up that this is marked as RB-Beta and we are promoting to Beta on Thursday. Next M64 Dev is also scheduled for tomorrow. Is fix in #2 already in Canary? Is it ready to be merged to M64 branch yet?
,
Dec 13 2017
sdy@, do we have any latest update on this? If it's not a 'Beta' blocker please feel free to change the priority as we are targeting M64 Beta release tomorrow. Thank you!
,
Dec 13 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/30999dd424c2e897fbe53e606189f55d83b98a4f commit 30999dd424c2e897fbe53e606189f55d83b98a4f Author: Sidney San Martín <sdy@chromium.org> Date: Wed Dec 13 22:49:46 2017 Work around a High Sierra fullscreen bug by getting rid of fractional pixel differences in video aspect ratio. When a 720x1280 video is made fullscreen on a 1440x900 DIP screen, this happens to its dimensions: 720x1280 -[scale]-> 506.25x900 -[integer]-> 506x900 The AVSampleBufferDisplayLayer used for video content layers has its videoGravity set to AVLayerVideoGravityResize, which doesn't preserve aspect ratio. Under certain circumstances, the small difference in aspect ratio triggers a macOS bug with low power detachment where the video's x position changes rapidly each frame as long as the window stays in detached mode. I've been able to make it happen if: - The machine is a MacBook Pro. - The OS is at least 10.13. - The display is set to native 2x resolution ("Looks like 1440x900"). - The machine is running on integrated graphics if it has dual graphics. A recording of the issue is attached to the crbug. This workaround is sort of terrible and maybe Apple can suggest a better one: when a video layer's aspect ratio can be made to exactly match the source aspect ratio by adding a fractional pixel to either dimension, do so (making sure to keep the video centered). Bug: 792632 Change-Id: I8b149606cbccb6033c36d3ad400f7a63a4d462ce Reviewed-on: https://chromium-review.googlesource.com/812114 Commit-Queue: Sidney San Martín <sdy@chromium.org> Reviewed-by: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/heads/master@{#523924} [modify] https://crrev.com/30999dd424c2e897fbe53e606189f55d83b98a4f/ui/accelerated_widget_mac/ca_layer_tree_unittest_mac.mm [modify] https://crrev.com/30999dd424c2e897fbe53e606189f55d83b98a4f/ui/accelerated_widget_mac/ca_renderer_layer_tree.h [modify] https://crrev.com/30999dd424c2e897fbe53e606189f55d83b98a4f/ui/accelerated_widget_mac/ca_renderer_layer_tree.mm
,
Dec 13 2017
,
Dec 14 2017
Your change meets the bar and is auto-approved for M64. Please go ahead and merge the CL to branch 3282 manually. Please contact milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 15 2017
sdy@, Please merge the above fix to M64 branch: 3282 when you get a chance. Also i'm not able to replicate this issue on reported chrome version# for OS X 10.13.x and wondering this might be specific to 2017 GPU config (which test team doesn't have at the moment)? Thank you!
,
Dec 16 2017
manoranjanr@: Merging now. It's possible that it's GPU-specific, but I'm not sure. What's the machine you're testing with? It's also important that resolution is set to "Looks like 1440x900" and a screen recording isn't in progress. If you have Quartz Debug (or can download it from the Apple Developer site, it's part of Additional Tools for Xcode), try running it and turning on "Show Detached Regions" in the Tools menu. The screen should be tinted rad, and the tint should disappear or change to blue or green when the video is playing fullscreen. If that doesn't happen, something is stopping the window from becoming detached (a screen recording, the system is running on the discrete GPU, the video controls are visible, etc.). If the tint changes but the flicker doesn't happen, then either the resolution isn't right, or it only happens with the 2017 hardware (which would be interesting to know).
,
Dec 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/cc59dcdeb9807c6c16f08527651ded12acf5d289 commit cc59dcdeb9807c6c16f08527651ded12acf5d289 Author: Sidney San Martín <sdy@chromium.org> Date: Sat Dec 16 20:01:34 2017 Work around a High Sierra fullscreen bug by getting rid of fractional pixel differences in video aspect ratio. When a 720x1280 video is made fullscreen on a 1440x900 DIP screen, this happens to its dimensions: 720x1280 -[scale]-> 506.25x900 -[integer]-> 506x900 The AVSampleBufferDisplayLayer used for video content layers has its videoGravity set to AVLayerVideoGravityResize, which doesn't preserve aspect ratio. Under certain circumstances, the small difference in aspect ratio triggers a macOS bug with low power detachment where the video's x position changes rapidly each frame as long as the window stays in detached mode. I've been able to make it happen if: - The machine is a MacBook Pro. - The OS is at least 10.13. - The display is set to native 2x resolution ("Looks like 1440x900"). - The machine is running on integrated graphics if it has dual graphics. A recording of the issue is attached to the crbug. This workaround is sort of terrible and maybe Apple can suggest a better one: when a video layer's aspect ratio can be made to exactly match the source aspect ratio by adding a fractional pixel to either dimension, do so (making sure to keep the video centered). TBR=sdy@chromium.org (cherry picked from commit 30999dd424c2e897fbe53e606189f55d83b98a4f) Bug: 792632 Change-Id: I8b149606cbccb6033c36d3ad400f7a63a4d462ce Reviewed-on: https://chromium-review.googlesource.com/812114 Commit-Queue: Sidney San Martín <sdy@chromium.org> Reviewed-by: ccameron <ccameron@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#523924} Reviewed-on: https://chromium-review.googlesource.com/830899 Reviewed-by: Sidney San Martín <sdy@chromium.org> Cr-Commit-Position: refs/branch-heads/3282@{#253} Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840} [modify] https://crrev.com/cc59dcdeb9807c6c16f08527651ded12acf5d289/ui/accelerated_widget_mac/ca_layer_tree_unittest_mac.mm [modify] https://crrev.com/cc59dcdeb9807c6c16f08527651ded12acf5d289/ui/accelerated_widget_mac/ca_renderer_layer_tree.h [modify] https://crrev.com/cc59dcdeb9807c6c16f08527651ded12acf5d289/ui/accelerated_widget_mac/ca_renderer_layer_tree.mm
,
Dec 20 2017
sdy@, thank you for providing all debugging info. I spent sometime today to figure it out the actual issue and able to see some difference before and after fix (It's not exactly same as the reported one, however there is a renderer glitch while full screen entering into detaching mode). Bad# 64.0.3274.0 Good# Latest Build with the above fix (> #65.0.3293.0) PS: Recently got my personal 2017 MBP, i'll try to see if i can replicate the same issue there. Thank you! |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by sdy@chromium.org
, Dec 6 20178.1 MB
8.1 MB View Download