| commit | 54597980fe214183b6548df4abacd78f46eb8ae3 | |
| author | miu@chromium.org <miu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | |
| Wed, 6 Feb 2013 01:59:55 +0000 (6 01:59 +0000) | ||
| committer | miu@chromium.org <miu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | |
| Wed, 6 Feb 2013 01:59:55 +0000 (6 01:59 +0000) | ||
| tree | 1002e94600e12c68926c7bfe14959bed367e677f | treesnapshot (tar.gz zip) |
| parent | bba3a3eadf7d534de76c599eeaa3afc064f11dae | commitdiff |
While screencasting a tab, do not disable rendering updates while hidden.
Approach: There is already a mechanism in WebContentsImpl to prevent WasHidden() from bubbling down to RWHV during tab dragging. This mechanism is extended to also include the span of tab mirroring sessions. A counter is used to account for both dragging a tab and screencasting it at the same time.
Fixed a bug in tab_drag_controller.cc where SetCapturingContents(false) was not being called after a drag in some circumstances.
Note on GTK-specific drag controller change: WebContents::SetCapturingContents(true) is never called, making the Set(false) call a no-op. Removed the Set(false) call and confirmed this did not affect tab dragging behavior on Linux.
BUG=154184
TEST=Win/Mac/Linux: Tested that hidden tabs continue to render with both GPU and software compositing paths. Also, ran through several tab dragging scenarios with and without screencasting engaged.
Review URL: https://chromiumcodereview.appspot.com/12179007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@180857 0039d316-1c4b-4281-b951-d872f2087c98
Approach: There is already a mechanism in WebContentsImpl to prevent WasHidden() from bubbling down to RWHV during tab dragging. This mechanism is extended to also include the span of tab mirroring sessions. A counter is used to account for both dragging a tab and screencasting it at the same time.
Fixed a bug in tab_drag_controller.cc where SetCapturingContents(false) was not being called after a drag in some circumstances.
Note on GTK-specific drag controller change: WebContents::SetCapturingContents(true) is never called, making the Set(false) call a no-op. Removed the Set(false) call and confirmed this did not affect tab dragging behavior on Linux.
BUG=154184
TEST=Win/Mac/Linux: Tested that hidden tabs continue to render with both GPU and software compositing paths. Also, ran through several tab dragging scenarios with and without screencasting engaged.
Review URL: https://chromiumcodereview.appspot.com/12179007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@180857 0039d316-1c4b-4281-b951-d872f2087c98