| commit | a6ce94ca1e79305aa911d710cab084605c9d137f | |
| author | miu <miu@chromium.org> | |
| Tue, 31 Mar 2015 20:21:22 +0000 (31 13:21 -0700) | ||
| committer | Commit bot <commit-bot@chromium.org> | |
| Tue, 31 Mar 2015 20:21:55 +0000 (31 20:21 +0000) | ||
| tree | 051180816eb4759b088059587bca2dd51daacb0e | treesnapshot (tar.gz zip) |
| parent | f430a86adb5692940214d3b2d99f7975b96d1882 | commitdiff |
Re-land: De-dupe copy requests for tab capture in DelegatedFrameHost.
Tab capture requests copies/readbacks in response to every delegated
frame swap from the renderer. The requests are moved to, and then
executed on the compositor thread at a later time. Unfortunately, the
browser may not be composited for every render frame, and so multiple
copies/readbacks may become enqueued for the same compositor frame.
This change detects this scenario, and de-dupes by "aborting" the older
frame subscriber callback.
This is a reworking of the first attempt
(https://codereview.chromium.org/986823002/), which erroneously copied
into the aborted VideoFrame. This resulted in a weird "old frame"
flickering effect because, on slower machines, the VideoFrame had
already been recycled by a buffer pool for a newer copy request.
Rather than manage the queuing/de-duping in DelegatedFrameHost, DFH
simply creates copy requests with a "source" tag. Then, cc::Layer
de-dupes attempts to add multiple requests from the same "source."
BUG=464475,469345
Review URL: https://codereview.chromium.org/1016273005
Cr-Commit-Position: refs/heads/master@{#323094}
Tab capture requests copies/readbacks in response to every delegated
frame swap from the renderer. The requests are moved to, and then
executed on the compositor thread at a later time. Unfortunately, the
browser may not be composited for every render frame, and so multiple
copies/readbacks may become enqueued for the same compositor frame.
This change detects this scenario, and de-dupes by "aborting" the older
frame subscriber callback.
This is a reworking of the first attempt
(https://codereview.chromium.org/986823002/), which erroneously copied
into the aborted VideoFrame. This resulted in a weird "old frame"
flickering effect because, on slower machines, the VideoFrame had
already been recycled by a buffer pool for a newer copy request.
Rather than manage the queuing/de-duping in DelegatedFrameHost, DFH
simply creates copy requests with a "source" tag. Then, cc::Layer
de-dupes attempts to add multiple requests from the same "source."
BUG=464475,469345
Review URL: https://codereview.chromium.org/1016273005
Cr-Commit-Position: refs/heads/master@{#323094}