FS-within-tab UI sets web rendering size to capture resolution to resolve both quality and UX issues |
||
Issue descriptionBackground: While tab capture is active, if a page goes fullscreen, an alternate browser UI is provided: The browser window does not go fullscreen, and the web page becomes surrounded by gray matte, and the web page continues to be rendered within the tab. This allows the user to switch to other tabs/apps on their desktop while capture is remoting content to another device. Problem 1: For a long time, the web page will see that it's size is something much smaller what a fullscreened page would normally be. For example, because it is still rendered within a tab, the page would detect its size at something like 600x400 to 900x600. Thus, most video streaming sites will choose to download the standard definition content and not the high-definition content. Problem 2: In some cases, a page will make size assumptions when rendering fullscreened media controls; and so these controls will become obnoxiously-sized on the both the local screen and the remote screen (where the captured video is played out). Problem 3: Because tab capture is often capturing at a high-def resolution, such as 1080p; having the web page render at a smaller size means we must execute expensive scaling operations on the GPU. In addition, because the web page sizes are very arbitrary (based on the browser window's size), there is quality degradation in most of these scaling operations (because the scale factor is almost never an integer multiple). Solution: When a page enters fullscreen mode, it's rendering size should be set to the native tab video capture resolution. However, it will then need to be scaled to fit on the local screen in the browser tab content area. Prototypes show this delivers a number of benefits: 1) Pages download high-def streams and can be tab-captured without scaling, improving quality and performance; 2) the controls are still interactable locally, and are almost always a reasonable size for practical use; 3) the down-scaling of the tab content for display in the local UI is cheaper; 4) the down-scaled tab content view with the gray matte surrounding is a much better indication/reminder to the user that the page content is being captured and remoted.
,
Oct 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/337049f6365b841fa90f07027b54db8ad5431ef3 commit 337049f6365b841fa90f07027b54db8ad5431ef3 Author: Adam Parker <amp@chromium.org> Date: Wed Oct 25 06:44:31 2017 [Views] Tab capture fullscreen UI: Render page at video resolution. This change adds a native view size property to the native view host and resizes the local view based on that size if it doesn't match the native view size when capturing content while fullscreen in tab. The visible UI changes are subtle, resolution changes (resizing the window etc) will no longer affect the captured render resolution while still providing a usable scaled view locally. The user impact will be a significant quality improvement for the captured video as rendered. Previously the captured content would be based on the the content scaled to the current view which was likely much lower than the possible render resolution and would often be scaled up again. After this change the capture output will be based on the original video resolution and will not be scaled down for the local view before hand (it will be scaled down for the local view if the capture size is larger). Derived from an unpublished prototype by miu@ https://codereview.chromium.org/2654413002/ Bug: 516188,692790 Change-Id: Ie681137f2fe684074bb5e719d289c213c0b1e4a7 Reviewed-on: https://chromium-review.googlesource.com/619726 Commit-Queue: Adam Parker <amp@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Trent Apted <tapted@chromium.org> Reviewed-by: Yuri Wiitala <miu@chromium.org> Cr-Commit-Position: refs/heads/master@{#511395} [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/content/browser/media/capture/web_contents_video_capture_device.cc [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/aura/window.h [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/compositor/layer.cc [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/compositor/layer.h [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/native/native_view_host.cc [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/native/native_view_host.h [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/native/native_view_host_aura.cc [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/native/native_view_host_aura.h [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/native/native_view_host_aura_unittest.cc [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/native/native_view_host_mac.h [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/native/native_view_host_mac.mm [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/native/native_view_host_mac_unittest.mm [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/native/native_view_host_wrapper.h [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/webview/webview.cc [modify] https://crrev.com/337049f6365b841fa90f07027b54db8ad5431ef3/ui/views/controls/webview/webview_unittest.cc
,
May 17 2018
|
||
►
Sign in to add a comment |
||
Comment 1 by amp@chromium.org
, Sep 12 2017